Re: Something fishy happening on frogmouth

Heikki Linnakangas <hlinnakangas@vmware.com>

From: Heikki Linnakangas <hlinnakangas@vmware.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Andres Freund <andres@2ndquadrant.com>, Andrew Dunstan <andrew@dunslane.net>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2013-10-31T09:33:28Z
Lists: pgsql-hackers
On 30.10.2013 18:52, Robert Haas wrote:
> Here's a short summary of what I posted back in August: at system
> startup time, the postmaster creates one dynamic shared segment,
> called the control segment.  That segment sticks around for the
> lifetime of the server and records the identity of any *other* dynamic
> shared memory segments that are subsequently created.  If the server
> dies a horrible death (e.g. kill -9), the next postmaster will find
> the previous control segment (whose ID is written to a file in the
> data directory) and remove any leftover shared memory segments from
> the previous run; without this, such segments would live until the
> next server reboot unless manually removed by the user (which isn't
> even practical on all platforms; e.g. there doesn't seem to be any way
> to list all exstant POSIX shared memory segments on MacOS X, so a user
> wouldn't know which segments to remove).

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.

- Heikki


Commits

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

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