On Thu, Oct 31, 2013 at 10:29 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Thu, Oct 31, 2013 at 5:50 AM, Andres Freund <and...@2ndquadrant.com> >> wrote: >>> On 2013-10-31 11:33:28 +0200, Heikki Linnakangas wrote: >>>> Wait, that sounds horrible. If you kill -9 the server, and then rm -rf >>>> $PGDATA, the shared memory segment is leaked until next reboot? > >>> Our main shared memory segment works the same way, doesn't it? And it >>> has for a long time. > >> It does, and what's the alternative, anyway? > > Well, what we expect from the existing shmem code is that restarting the > postmaster will clean things up, ie find and destroy the leaked shmem. > It sounds to me like this may not work like that, in which case I agree > with Heikki that it's not really acceptable.
I'm getting a little frustrated. It *does* work like that. I sent an email explaining that yesterday, and Andres sent another one this morning. Let me say this again: the dynamic shared memory code *does* clean up after itself. If you kill -9 the postmaster and all of its children, you'll orphan the main shared memory segment and any dynamic shared memory segments that exist. There is nothing we can do about that. When you restart the postmaster, both the main shared memory segment and any dynamic shared memory segments orphaned by the previous kill will be cleaned up. I spent a lot of time trying to make sure that the handling of dynamic shared memory segments is, in all cases, as parallel to the handling of the main shared memory segment as possible. There should be no cases where the main shared memory segment gets cleaned up and the dynamic shared memory segments do not. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
