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
-
Initialize random() in bootstrap/stand-alone postgres and in initdb.
- 402da7054f34 9.3.25 landed
- 401228183a63 9.4.20 landed
- d68d5adfdcae 9.5.15 landed
- 89f2b64da370 11.0 landed
- 4232cff11b84 10.6 landed
- 329cacb90270 9.6.11 landed
- d18f6674bd60 12.0 landed
-
Modify dynamic shared memory code to use Size rather than uint64.
- d2aecaea1555 9.4.0 cited