pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Heikki Linnakangas <hlinnakangas@vmware.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@2ndquadrant.com>
Cc: Andrew Dunstan <andrew@dunslane.net>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Subject: Re: Something fishy happening on frogmouth
Date: Thu, 31 Oct 2013 11:33:28 +0200
Message-ID: <527223E8.2020207@vmware.com> (raw)
In-Reply-To: <CA+TgmobOqYVBD=xdWHF12R4+dxeBDS3ruxware7ZWtD5mfSO5Q@mail.gmail.com>
References: <6557.1383073940@sss.pgh.pa.us>
	<CA+Tgmob859sdnDuHAF31BE55qEoREnCzzWeqDbgkNB0d_F+zmA@mail.gmail.com>
	<27889.1383139602@sss.pgh.pa.us>
	<20131030133718.GB11429@awork2.anarazel.de>
	<28492.1383140966@sss.pgh.pa.us>
	<CA+TgmobOqYVBD=xdWHF12R4+dxeBDS3ruxware7ZWtD5mfSO5Q@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers



view thread (38+ messages)  latest in thread

Message-ID: <527223E8.2020207@vmware.com>
Permalink:  ../527223E8.2020207@vmware.com/
Also on:    postgresql.org/message-id/527223E8.2020207@vmware.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: hlinnakangas@vmware.com, robertmhaas@gmail.com, tgl@sss.pgh.pa.us, andres@2ndquadrant.com, andrew@dunslane.net
  Subject: Re: Something fishy happening on frogmouth
  In-Reply-To: <527223E8.2020207@vmware.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox