Thread: pg 7.3 memory error
Hi, by atempt to create a group of indexes ( pg 7.3 + redhat 7.3), the postgres crashes with the this error: LOG: recycled transaction log file 00000000000000AC LOG: recycled transaction log file 00000000000000AD LOG: recycled transaction log file 00000000000000AF LOG: recycled transaction log file 00000000000000B0 LOG: recycled transaction log file 00000000000000AE LOG: recycled transaction log file 00000000000000B2 LOG: recycled transaction log file 00000000000000B3 LOG: recycled transaction log file 00000000000000B1 LOG: recycled transaction log file 00000000000000B4 LOG: recycled transaction log file 00000000000000B5 LOG: recycled transaction log file 00000000000000B6 LOG: recycled transaction log file 00000000000000B7 LOG: recycled transaction log file 00000000000000B8 LOG: recycled transaction log file 00000000000000B9 LOG: recycled transaction log file 00000000000000BA LOG: recycled transaction log file 00000000000000BB LOG: recycled transaction log file 00000000000000BC LOG: recycled transaction log file 00000000000000BD LOG: recycled transaction log file 00000000000000BE LOG: recycled transaction log file 00000000000000BF LOG: recycled transaction log file 00000000000000C0 LOG: recycled transaction log file 00000000000000C1 LOG: recycled transaction log file 00000000000000C2 LOG: recycled transaction log file 00000000000000C3 LOG: recycled transaction log file 00000000000000C4 LOG: recycled transaction log file 00000000000000C5 LOG: recycled transaction log file 00000000000000C6 LOG: recycled transaction log file 00000000000000C7 LOG: recycled transaction log file 00000000000000C8 LOG: recycled transaction log file 00000000000000C9 LOG: recycled transaction log file 00000000000000CA LOG: recycled transaction log file 00000000000000CB LOG: recycled transaction log file 00000000000000CC LOG: recycled transaction log file 00000000000000CD LOG: recycled transaction log file 00000000000000CE LOG: recycled transaction log file 00000000000000CF LOG: recycled transaction log file 00000000000000D0 LOG: recycled transaction log file 00000000000000D1 LOG: recycled transaction log file 00000000000000D2 LOG: recycled transaction log file 00000000000000D3 LOG: recycled transaction log file 00000000000000D4 LOG: recycled transaction log file 00000000000000D5 LOG: recycled transaction log file 00000000000000D6 LOG: recycled transaction log file 00000000000000D7 LOG: recycled transaction log file 00000000000000D8 LOG: recycled transaction log file 00000000000000D9 LOG: recycled transaction log file 00000000000000DA LOG: recycled transaction log file 00000000000000DB LOG: recycled transaction log file 00000000000000DC LOG: recycled transaction log file 00000000000000DD LOG: recycled transaction log file 00000000000000DE LOG: recycled transaction log file 00000000000000DF LOG: recycled transaction log file 00000000000000E0 ERROR: MemoryContextAlloc: invalid request size 4294967293 Any idea will help. regards.
pginfo <pginfo@t1.unisoftbg.com> writes:
> ERROR: MemoryContextAlloc: invalid request size 4294967293
I'm guessing that you have corrupted data in one of your tables.
There's no info in either of your messages that would help in narrowing
that down, however.
regards, tom lane
Hi Tom, As I wrote it happens by indexing. And all the data are new inserted (after dumping from 7.2 from anoder box before). I do not belive that it is data corruption. Also the pg dies from time to time. What info can I send that will help? regards, ivan. Tom Lane wrote: > pginfo <pginfo@t1.unisoftbg.com> writes: > > ERROR: MemoryContextAlloc: invalid request size 4294967293 > > I'm guessing that you have corrupted data in one of your tables. > There's no info in either of your messages that would help in narrowing > that down, however. > > regards, tom lane
pginfo <pginfo@t1.unisoftbg.com> writes:
> As I wrote it happens by indexing.
> And all the data are new inserted (after dumping from 7.2 from anoder box
> before).
> I do not belive that it is data corruption.
Hm. Another theory that would fit those facts is that you're getting
bitten by the bug in strcoll() that used to exist in glibc. I think you
said you are using Red Hat somethingorother --- are you up2date on glibc
fixes?
regards, tom lane
Hi Tom, Tom Lane wrote: > pginfo <pginfo@t1.unisoftbg.com> writes: > > As I wrote it happens by indexing. > > And all the data are new inserted (after dumping from 7.2 from anoder box > > before). > > I do not belive that it is data corruption. > > Hm. Another theory that would fit those facts is that you're getting > bitten by the bug in strcoll() that used to exist in glibc. I think you > said you are using Red Hat somethingorother --- are you up2date on glibc > fixes? > Actualy no.But I am using this version of redhat (7.3) without any problems with pg 7.2.3. And it is working very well. Is it possible that the problem is in my shared memory configuration? Also I use it with the latest jdbc driver from pg (7.3) > regards, tom lane regards, ivavn.
hi tom, did you look into my thread named "Kenel BUG" from saturday? any idea? it didn't happen again yet, but maybe there really is a problem somewhere? -- Mit freundlichem Gruß Henrik Steffen Geschäftsführer top concepts Internetmarketing GmbH Am Steinkamp 7 - D-21684 Stade - Germany -------------------------------------------------------- http://www.topconcepts.com Tel. +49 4141 991230 mail: steffen@topconcepts.com Fax. +49 4141 991233 -------------------------------------------------------- 24h-Support Hotline: +49 1908 34697 (EUR 1.86/Min,topc) -------------------------------------------------------- System-Partner gesucht: http://www.franchise.city-map.de -------------------------------------------------------- Handelsregister: AG Stade HRB 5811 - UstId: DE 213645563 -------------------------------------------------------- Falls Ihr eMail Programm das angehängte digitale Zerti- fikat nicht unterstützt, können Sie es einfach ignorie- ren. Ein eigenes digitales Zertifikat können Sie kosten- los beantragen unter: http://www.trustcenter.de -------------------------------------------------------- ----- Original Message ----- From: "Tom Lane" <tgl@sss.pgh.pa.us> To: "pginfo" <pginfo@t1.unisoftbg.com> Cc: "pgsql-general" <pgsql-general@postgresql.org> Sent: Monday, December 09, 2002 3:45 PM Subject: Re: [GENERAL] pg 7.3 memory error > pginfo <pginfo@t1.unisoftbg.com> writes: > > As I wrote it happens by indexing. > > And all the data are new inserted (after dumping from 7.2 from anoder box > > before). > > I do not belive that it is data corruption. > > Hm. Another theory that would fit those facts is that you're getting > bitten by the bug in strcoll() that used to exist in glibc. I think you > said you are using Red Hat somethingorother --- are you up2date on glibc > fixes? > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
pginfo <pginfo@t1.unisoftbg.com> writes:
>> Hm. Another theory that would fit those facts is that you're getting
>> bitten by the bug in strcoll() that used to exist in glibc. I think you
>> said you are using Red Hat somethingorother --- are you up2date on glibc
>> fixes?
> Actualy no.But I am using this version of redhat (7.3) without any problems
> with pg 7.2.3.
> And it is working very well.
But 7.2.3 does not depend on strcoll() in the default configuration.
7.3 does (unless you were careful to initdb in locale "C").
regards, tom lane
Hi, it is possible to be glibc problem. Witch version of glibc will be good ( or to upgrade to RH 8.0) ? Exists any one using pg 7.3 on RH 7.3/8.0 ? Bay the way pg 7.3 is very good as performance ! regards, ivan. Tom Lane wrote: > pginfo <pginfo@t1.unisoftbg.com> writes: > >> Hm. Another theory that would fit those facts is that you're getting > >> bitten by the bug in strcoll() that used to exist in glibc. I think you > >> said you are using Red Hat somethingorother --- are you up2date on glibc > >> fixes? > > > Actualy no.But I am using this version of redhat (7.3) without any problems > > with pg 7.2.3. > > And it is working very well. > > But 7.2.3 does not depend on strcoll() in the default configuration. > 7.3 does (unless you were careful to initdb in locale "C"). > > regards, tom lane
Hi, I checket the redhat 7.3 and glibc and by it is 2.2.5. I think it exist only one stable glibc ( 2.3.1 ) after 2.2.5. regards, ivan. Tom Lane wrote: > pginfo <pginfo@t1.unisoftbg.com> writes: > >> Hm. Another theory that would fit those facts is that you're getting > >> bitten by the bug in strcoll() that used to exist in glibc. I think you > >> said you are using Red Hat somethingorother --- are you up2date on glibc > >> fixes? > > > Actualy no.But I am using this version of redhat (7.3) without any problems > > with pg 7.2.3. > > And it is working very well. > > But 7.2.3 does not depend on strcoll() in the default configuration. > 7.3 does (unless you were careful to initdb in locale "C"). > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
pginfo <pginfo@t1.unisoftbg.com> writes: > I checket the redhat 7.3 and glibc and by it is 2.2.5. Okay, that theory's out then. According to our archives the strcoll bug was fixed in glibc release 2.2.3 --- see eg http://fts.postgresql.org/db/mw/msg.html?mid=1038314 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=36539 Can you get a stack backtrace from the core dump? (See our archives for details if you don't know about ulimit, gdb, etc) regards, tom lane