"Gordon Ross" <[EMAIL PROTECTED]> 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 running on 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, whenever I tried to access either the base table
> or child tables, I get the message saying that pgsql has lost communication with 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
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
