Re: Problems dumping database from 7.3.1

*SIGH* Oh, well. I suppose I should have updated up development machine a while ago. ./configure; make here we come.

Thank you for looking at this. At least I can be re-assured that the problem is fixed in later versions of Postgres.

GTG

>>> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 05/12/04 20:36 PM >>>
"Gordon Ross" <G(dot)Ross(at)ccw(dot)gov(dot)uk> writes:
> switchboards=# select * from "DNOwner";
> server closed the connection unexpectedly

> 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.

Hmm. Does 'select * from only "DNOwner";' work, by any chance?

I have a suspicion now that you were bit by the bug repaired in this
7.3.2 bug fix:

2003-01-04 19:56 tgl

* src/backend/optimizer/prep/prepunion.c (REL7_3_STABLE): Fix
inherited UPDATE for cases where child column numbering doesn't
match parent table. This used to work, but was broken in 7.3 by
rearrangement of code that handles targetlist sorting. Add a
regression test to catch future breakage.

What I am thinking happened is that you did an 'UPDATE "DNOwner"' to
insert values for the new column, and that because of the aforesaid
bug, the updates of the child tables actually corrupted the data (by
storing the intended new dnid value into the wrong column position).
The crash is probably happening because SELECT is trying to interpret
an integer as a text field, or something along that line.

If that theory is correct, then the parent table should still be okay
(thus the request to try an ONLY select). However, I'm afraid all your
child tables are toast, or at least all the rows you updated this way
are toast. You could maybe get to a dumpable state by deleting all the
child rows, but if the DELETE crashes then you'll have little recourse
but to drop the child tables completely.

Updating Postgres to 7.3.2 or later will prevent fresh occurrences of
the same problem, but unfortunately won't bring back your old data :-(.
I hope you have backups ...

regards, tom lane