Just compiled PG 7.3.4 with GCC 3.1 on Panther and it exhibits the same problem, but generates a SIGSEGV instead of a SIGBUS. Here's the log:

LOG: server process (pid 12078) was terminated by signal 11
LOG: terminating any other active server processes
LOG: all server processes terminated; reinitializing shared memory and semaphores
LOG: database system was interrupted at 2003-11-06 14:19:26 CST
LOG: checkpoint record is at 0/80212C
LOG: redo record is at 0/80212C; undo record is at 0/0; shutdown TRUE
LOG: next transaction id: 480; next oid: 16976
LOG: database system was not properly shut down; automatic recovery in progress
LOG: redo starts at 0/80216C
LOG: ReadRecord: record with zero length at 0/81E754
LOG: redo done at 0/81E730
LOG: database system is ready


A reboot does not help -- it still fails. I recompiled at GCC 3.1 and it's failing at pltcl load again. I rebooted, then tried to add the languages again. plpgsql was already loaded from the last time, but shared memory failed again when it tried to load pltcl.

ipcs isn't installed on Panther. Strangely though, I've found ipcs in the Darwin source tree (previous version) under /usr/bin, and in the same place in FreeBSD source tree.

/s.




On Nov 6, 2003, at 2:41 PM, Tom Lane wrote:


Scott Goodwin <[EMAIL PROTECTED]> writes:
psql:/Users/scott/m/ops/database/sql/add_languages.sql:13: server
closed the connection unexpectedly
         This probably means the server terminated abnormally
         before or while processing the request.

...output in the log file is:

LOG: server process (PID 2739) was terminated by signal 10

Here's the real problem --- why are you getting a SIGBUS while trying to
load the pltcl handler function? I suspect something broken in Tcl's
shared library, but dunno what. You should be getting a core file from
the crashed process --- can you get a stack trace from it with gdb?


FATAL:  could not create shared memory segment: Cannot allocate memory
DETAIL:  Failed system call was shmget(key=5432001, size=3809280,
03600).

This is evidently happening during attempted restart after the backend crash. I suspect it is a matter of the OS not having released the old memory segment yet, together with the SHMMAX limit being too tight to allow two such segments to exist concurrently. Are you able to start the server by hand immediately afterwards, or a few seconds afterwards? Or do you have to reboot before it will restart?

regards, tom lane


---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Reply via email to