Re: pg_dump core dumping
От | Tom Lane |
---|---|
Тема | Re: pg_dump core dumping |
Дата | |
Msg-id | 10945.1051375973@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | pg_dump core dumping (Chris Bowlby <excalibur@hub.org>) |
Ответы |
Re: pg_dump core dumping
|
Список | pgsql-bugs |
Chris Bowlby <excalibur@hub.org> writes: > (gdb) bt > #0 0x280880ac in getRowDescriptions (conn=0x8068200) at fe-exec.c:1027 > #1 0x28087eaa in parseInput (conn=0x8068200) at fe-exec.c:919 > #2 0x28088525 in PQgetResult (conn=0x8068200) at fe-exec.c:1249 > #3 0x280886b9 in PQexec (conn=0x8068200, query=0x8076600 "SELECT adsrc > from pg_attrdef where adrelid = '16721225'::oid and adnum = 8 ") at > fe-exec.c:1362 Bizarre. What happens if you try that same SELECT from psql? (I'd sort of expect psql to blow up too, but it'd be worth confirming.) How about variants such as "SELECT length(adsrc) FROM ..." ? Can you do a \d on whichever table has OID 16721225? I'm guessing that that row of pg_attrdef is somehow corrupt, but why the corruption would crash the client rather than the backend escapes me ... regards, tom lane
В списке pgsql-bugs по дате отправления: