Re: invalid memory alloc request size

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Janning Vygen <vygen(at)gmx(dot)de>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: invalid memory alloc request size
Date: 2006-01-23 19:30:21
Message-ID: 7698.1138044621@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Janning Vygen <vygen(at)gmx(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Rick Gigger 2006-01-23 19:37:06 Re: Linux - postgres RAID
Previous Message Vivek Khera 2006-01-23 19:21:08 Re: RAID 5 and postgresql