Re: BUG #7885: postmaster panic on startup does not release shared memory - Mailing list pgsql-bugs

From Bruce Momjian
Subject Re: BUG #7885: postmaster panic on startup does not release shared memory
Date
Msg-id 20130215204229.GE12030@momjian.us
Whole thread Raw
In response to BUG #7885: postmaster panic on startup does not release shared memory  (david.thomas@enterprisedb.com)
Responses Re: BUG #7885: postmaster panic on startup does not release shared memory  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
When we panic, we PANIC, meaning we don't jump around looking for
cleanup stuff, which might make things worse.  Postgres should never
panic, so it would be good if you found the cause of the panic.

Does restarting the server remove the old shared memory stuff?

---------------------------------------------------------------------------

On Fri, Feb 15, 2013 at 06:33:21PM +0000, david.thomas@enterprisedb.com wrote:
> The following bug has been logged on the website:
>
> Bug reference:      7885
> Logged by:          David Thomas
> Email address:      david.thomas@enterprisedb.com
> PostgreSQL version: 9.2.3
> Operating system:   CentOS 6.3
> Description:
>
> It seems that if the postmaster encounters a PANIC condition during startup,
> it leaves it's allocated shared memory segments around:
>
> -bash-4.1$ ipcs -a
>
> ------ Shared Memory Segments --------
> key        shmid      owner      perms      bytes      nattch     status
>
> ------ Semaphore Arrays --------
> key        semid      owner      perms      nsems
>
> ------ Message Queues --------
> key        msqid      owner      perms      used-bytes   messages
>
> -bash-4.1$ /usr/pgsql-9.2/bin/postmaster --single -D
> /var/lib/pgsql/9.2/data/ test
> PANIC:  could not locate a valid checkpoint record
> Aborted
> -bash-4.1$ ipcs -a
>
> ------ Shared Memory Segments --------
> key        shmid      owner      perms      bytes      nattch     status
> 0x00000001 753664     postgres   600        41279488   0
>
> ------ Semaphore Arrays --------
> key        semid      owner      perms      nsems
> 0x00000001 5439490    postgres   600        17
> 0x00000002 5472259    postgres   600        17
> 0x00000003 5505028    postgres   600        17
> 0x00000004 5537797    postgres   600        17
> 0x00000005 5570566    postgres   600        17
> 0x00000006 5603335    postgres   600        17
> 0x00000007 5636104    postgres   600        17
>
> ------ Message Queues --------
> key        msqid      owner      perms      used-bytes   messages
>
> Considering that it was able to allocate this memory before the panic
> occurred, it should remove them before exiting.
>
>
>
> --
> Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +

pgsql-bugs by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: BUG #7874: GUC's not in database dumps
Next
From: nick.baxter@gmail.com
Date:
Subject: BUG #7886: date_trunc(date) returning timestamptz instead of timestamp