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
>> 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
In response to
pgsql-general by date
|Next:||From: Bruno Wolff III||Date: 2004-06-30 16:09:48|
|Subject: Re: DML Restriction unless through a function|
|Previous:||From: Tom Lane||Date: 2004-06-30 16:00:44|
|Subject: Re: DML Restriction unless through a function |