Re: Problems dumping database from 7.3.1 - Mailing list pgsql-admin

From Tom Lane
Subject Re: Problems dumping database from 7.3.1
Date
Msg-id 24210.1084367436@sss.pgh.pa.us
Whole thread Raw
In response to Problems dumping database from 7.3.1  ("Gordon Ross" <G.Ross@ccw.gov.uk>)
List pgsql-admin
"Gordon Ross" <G.Ross@ccw.gov.uk> writes:
> I've been using a PGSQL 7.3.1 system as my development box for some time, and so far, it worked fine. (This is
runningon Slackware distro with a 2.2.19 kernel under VMWare 4) 
> However, yesterday, I added a column to a base table (that is inherited by several other tables). Shortly afterwards,
wheneverI tried to access either the base table or child tables, I get the message saying that pgsql has lost
communicationwith the server. 

Sounds pretty messy.  If you're really lucky, an in-place update to
7.3.6 might fix it, but I can't offhand think of any bug fixes in the
7.3.* branch that had anything to do with inheritance.

Of course it's not necessarily true that this has anything to do with
inheritance, either.  What we'd need to know before we could speculate
much further is where exactly the crash is happening.  A gdb backtrace
from the SEGV would help a lot.  I'd suggest:

1. Start a psql session.  Figure out the PID of the connected backend
(pg_stat_activity may help, or just use "ps").

2. In another shell window, attach to the backend process with gdb:
    gdb /path/to/postgres-executable PID
    ...
    gdb>
(You can do this either as root or as the postgres user.)

3. Tell gdb to let the backend continue:
    gdb> cont

4. Do whatever it takes in the psql session to provoke crash.  gdb
should announce that the backend has gotten a signal 11.  Now say
    gdb> bt
    gdb> quit

and send along the output of bt.

            regards, tom lane

pgsql-admin by date:

Previous
From: "Gordon Ross"
Date:
Subject: Problems dumping database from 7.3.1
Next
From: "scott.marlowe"
Date:
Subject: Re: [PERFORM] Quad processor options