Skip site navigation (1) Skip section navigation (2)

Re: query failing with out of memory error message.

From: "Joe Maldonado" <jmaldonado(at)webehosting(dot)biz>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: query failing with out of memory error message.
Date: 2004-06-30 16:08:57
Message-ID: opsae0g7hc9utx1k@localhost (view raw, whole thread or download thread mbox)
Lists: pgsql-general
On Tue, 29 Jun 2004 22:50:56 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:


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

> "Joe Maldonado" <jmaldonado(at)webehosting(dot)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

In response to


pgsql-general by date

Next:From: Bruno Wolff IIIDate: 2004-06-30 16:09:48
Subject: Re: DML Restriction unless through a function
Previous:From: Tom LaneDate: 2004-06-30 16:00:44
Subject: Re: DML Restriction unless through a function

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group