Re: query failing with out of memory error message.
От | Joe Maldonado |
---|---|
Тема | Re: query failing with out of memory error message. |
Дата | |
Msg-id | opsae0g7hc9utx1k@localhost обсуждение исходный текст |
Ответ на | Re: query failing with out of memory error message. (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: query failing with out of memory error message.
|
Список | pgsql-general |
On Tue, 29 Jun 2004 22:50:56 -0400, Tom Lane <tgl@sss.pgh.pa.us> wrote: Thanks! Where can I find a version of gp_filedump compatible with 7.4? > "Joe Maldonado" <jmaldonado@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 jmaldonado@webehosting.biz
В списке pgsql-general по дате отправления: