Re: Problems dumping database from 7.3.1

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Problems dumping database from 7.3.1
Дата
Msg-id 24210.1084367436@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Problems dumping database from 7.3.1  ("Gordon Ross" <G.Ross@ccw.gov.uk>)
Список 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 по дате отправления:

Предыдущее
От: "Gordon Ross"
Дата:
Сообщение: Problems dumping database from 7.3.1
Следующее
От: "scott.marlowe"
Дата:
Сообщение: Re: [PERFORM] Quad processor options