On Thu, Oct 31, 2013 at 10:29 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Thu, Oct 31, 2013 at 5:50 AM, Andres Freund <andres@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