query failing with out of memory error message.

[Joe Maldonado]

Hello all,
I have a seemingly corrupt row in a table and wanted to look at it's
contents.
when I try to query it I get the following...

db=# select * from some_table offset 411069 limit 1;
ERROR: invalid memory alloc request size 4294967293

but when I select individual fields within the record I get data.

Is there a way to read this row from the datafile to examine it closer?

--
Joe Maldonado
jm********@webehosting.biz

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

[Tom Lane]

"Joe Maldonado" <jm********@webehosting.biz> writes:

I have a seemingly corrupt row in a table and wanted to look at it's
contents.
when I try to query it I get the following... db=# select * from some_table offset 411069 limit 1;
ERROR: invalid memory alloc request size 4294967293 but when I select individual fields within the record I get data.
That's odd ... I'd certainly expect one or the other field of the table
to show that failure.
Is there a way to read this row from the datafile to examine it closer?

Select "ctid" from the troublesome row to determine its block and item
number, then dump out that block with pg_filedump. If there is data
corruption it'll usually be possible to see it in the pg_filedump dump.

Another line of attack is to attach to the backend process with gdb and
set a breakpoint at errfinish (or elog if a pre-7.4 backend), and then
get a stack trace back from the error report. This will help narrow
down exactly where the bogus allocation request is coming from.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

[Joe Maldonado]

On Tue, 29 Jun 2004 22:50:56 -0400, Tom Lane <tg*@sss.pgh.pa.us> wrote:

Thanks!

Where can I find a version of gp_filedump compatible with 7.4?

"Joe Maldonado" <jm********@webehosting.biz> writes:

I have a seemingly corrupt row in a table and wanted to look at it's
contents.
when I try to query it I get the following...

db=# select * from some_table offset 411069 limit 1;
ERROR: invalid memory alloc request size 4294967293

but when I select individual fields within the record I get data.

That's odd ... I'd certainly expect one or the other field of the table
to show that failure.

Is there a way to read this row from the datafile to examine it closer?

Select "ctid" from the troublesome row to determine its block and item
number, then dump out that block with pg_filedump. If there is data
corruption it'll usually be possible to see it in the pg_filedump dump.

Another line of attack is to attach to the backend process with gdb and
set a breakpoint at errfinish (or elog if a pre-7.4 backend), and then
get a stack trace back from the error report. This will help narrow
down exactly where the bogus allocation request is coming from.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

--
--
Joe Maldonado
jm********@webehosting.biz

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

[Tom Lane]

"Joe Maldonado" <jm********@webehosting.biz> writes:

Where can I find a version of pg_filedump compatible with 7.4?

http://sources.redhat.com/rhdb/

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly