From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | excalibur(at)hub(dot)org |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: pg_dump core dumping |
Date: | 2003-04-26 16:52:53 |
Message-ID: | 10945.1051375973@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Chris Bowlby <excalibur(at)hub(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Chris Bowlby | 2003-04-26 17:40:03 | Re: pg_dump core dumping |
Previous Message | Chris Bowlby | 2003-04-26 16:30:40 | pg_dump core dumping |