Re: invalid memory alloc request size - Mailing list pgsql-general

From Tom Lane
Subject Re: invalid memory alloc request size
Date
Msg-id 7698.1138044621@sss.pgh.pa.us
Whole thread Raw
In response to invalid memory alloc request size  (Janning Vygen <vygen@gmx.de>)
Responses Re: invalid memory alloc request size  (Janning Vygen <vygen@gmx.de>)
List pgsql-general
Janning Vygen <vygen@gmx.de> writes:
> Ok, i got the reffilnode from pg_class and compiled pg_filedump. result of
> ./pg_filedump -i -f -R 3397 /home/postgres8/data/base/12934120/12934361 >
> filedump.txt is attached

OK, what's the schema of this table exactly?  It looks like there are
a couple of text or varchar columns to start, but I'm not sure about the
last three columns.

> but i guess its item 49 which makes trouble
>   1258: 01000000 616c7465 68656964 65000000  ....alteheide...

> But it doesn't look very diffrent to item 48:
>   12a0: 0d000000 616c7465 68656964 65000000  ....alteheide...

If these are both supposed to be strings 'alteheide', then the problem
is the bogus length word on the first one: instead of starting with
01000000 it should start with 0d000000, like the second one does.

It's conceivable that this stems from a software problem, but I'm
wondering about hardware problems causing dropped bits, myself.

Another point is that AFAICS this tuple could not pose a problem for
DELETE all by itself, because it doesn't have any toasted fields.
Perhaps there is more corruption elsewhere.  Could you get a stack
trace from the crashed DELETE, rather than a crashed SELECT?

            regards, tom lane

pgsql-general by date:

Previous
From: Kovács Péter
Date:
Subject: Are indexes used with LIKE?
Next
From: Rick Gigger
Date:
Subject: Re: Linux - postgres RAID