Re: PostgreSQL 7.4RC1 crashes on Panther

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 <scott@scottg.net> 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