Re: pg_dump core dumping

On Sat, 2003-04-26 at 13:52, Tom Lane wrote:

 Ok, running the select statement that was used in the core file, I get
these results:

test=# SELECT adsrc from pg_attrdef where adrelid = '16721225'::oid and
adnum = 8 ;
 adsrc
-------
 'f'
(1 row)

 The table with OID 16721225 seems to work with out issue as well:

test=# select * from ec_picklist_items_audit;
 picklist_item_id | picklist_item | picklist_name | sort_key |
last_modified | last_modifying_user | modified_ip_address | delete_p

------------------+---------------+---------------+----------+---------------+---------------------+---------------------+----------
(0 rows)



> 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
--
Chris Bowlby <excalibur@hub.org>
Hub.Org Networking Services