Thread: BUG #7885: postmaster panic on startup does not release shared memory
BUG #7885: postmaster panic on startup does not release shared memory
From
david.thomas@enterprisedb.com
Date:
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.
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. +
Bruce Momjian <bruce@momjian.us> writes:
> When we panic, we PANIC, meaning we don't jump around looking for
> cleanup stuff, which might make things worse.
I think also there was some thought that we should intentionally leave
the shmem segment around for debugging purposes.
In any case, I believe the behavior complained of here is specific to
--single mode, which is surely not a production scenario, thus even
less reason to be concerned about it. (If a postmaster child panics,
the postmaster will still shut down normally and thus release the
shmem segment.)
regards, tom lane
On Fri, Feb 15, 2013 at 05:02:46PM -0500, Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > When we panic, we PANIC, meaning we don't jump around looking for > > cleanup stuff, which might make things worse. > > I think also there was some thought that we should intentionally leave > the shmem segment around for debugging purposes. > > In any case, I believe the behavior complained of here is specific to > --single mode, which is surely not a production scenario, thus even > less reason to be concerned about it. (If a postmaster child panics, > the postmaster will still shut down normally and thus release the > shmem segment.) > Yup, if I attempt to start the cluster normally, it cleans up after itself, so this is specific to --single mode. -- David Thomas System Engineer EnterpriseDB - The Enterprise PostgreSQL Company