Re: Problems dumping database from 7.3.1

switchboards=# \d "DNOwner";
Table "public.DNOwner"
Column | Type | Modifiers
-------------+---------+----------------------------------------------------
Id | integer | not null default nextval('"DNOwner_id_seq"'::text)
ExDirectory | boolean | default 'f'
Name | text |
dnid | integer |

switchboards=# select * from "DNOwner";
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.

The DNOwner table is the base table. There are other tables that inherit from this table, and doing a simple select on those produce the same result.

GTG

>>> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 05/12/04 17:51 PM >>>
"Gordon Ross" <G(dot)Ross(at)ccw(dot)gov(dot)uk> writes:
>> 4. Do whatever it takes in the psql session to provoke crash
>> and send along the output of bt.

> Program received signal SIGSEGV, Segmentation fault.
> 0x806ba0a in nocachegetattr () at eval.c:88
> 88 eval.c: No such file or directory.
> (gdb) bt
> #0 0x806ba0a in nocachegetattr () at eval.c:88
> #1 0x80d41ec in ExecEvalVar () at eval.c:88
> #2 0x80d549c in ExecEvalExpr () at eval.c:88
> #3 0x80d5809 in ExecTargetList () at eval.c:88

Hmm. The file/line references are obviously wrong, but let's assume
that the function names are right (they at least look plausible).
What exactly was the query that provoked this?
Also, could we see \d output for the table(s) involved?

regards, tom lane