Re: Something fishy happening on frogmouth

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>
To: Andres Freund <andres@2ndquadrant.com>
Cc: Heikki Linnakangas <hlinnakangas@vmware.com>, Tom Lane <tgl@sss.pgh.pa.us>, Andrew Dunstan <andrew@dunslane.net>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2013-10-31T12:06:48Z
Lists: pgsql-hackers
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? I find that
>> unacceptable. There are many scenarios where you never restart postmaster
>> after a crash. For example, if you have an automatic failover setup; you
>> fail over to the standby in case of crash, and re-initialize the old master
>> with e.g rsync.
>
> 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?  I mean, if the user or
the system decides to terminate all of the postgres processes on the
machine with extreme prejudice, like kill -9, we can't do anything
afterwards, and we can't do anything beforehand, either.  Of course,
it would be nice if there were an operating system API that said -
give me a named shared memory segment that automatically goes away
when the last active reference is gone.  But, except on Windows, no
such API appears to exist.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


Commits

  1. Initialize random() in bootstrap/stand-alone postgres and in initdb.

  2. Modify dynamic shared memory code to use Size rather than uint64.