Re: pg_dump core dumping

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

In response to

Responses

Browse pgsql-bugs by date

  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