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
