From: Stephen Frost <sfrost@snowman.net>
To: Noah Misch <noah@leadboat.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Weaker shmem interlock w/o postmaster.pid
Date: Wed, 11 Sep 2013 11:32:01 -0400
Message-ID: <20130911153200.GD2706@tamriel.snowman.net> (raw)
In-Reply-To: <20130911033341.GD225735@tornado.leadboat.com>
References: <20130911033341.GD225735@tornado.leadboat.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
* Noah Misch (noah@leadboat.com) wrote:
> Shouldn't it instead check the same things as PGSharedMemoryIsInUse()?
Offhand, I tend to agree that we should really be doing a very careful
job of looking at if an existing segment is still in use.
> The concrete situation in which I encountered this involved PostgreSQL 9.2 and
> an immediate shutdown with a backend that had blocked SIGQUIT. The backend
> survived the immediate shutdown as one would expect.
Well.. We expect this now because of the analysis you did in the
adjacent thread showing how it can happen.
> The postmaster
> nonetheless removed postmaster.pid before exiting, and I could immediately
> restart PostgreSQL despite the survival of the SIGQUIT-blocked backend. If I
> instead SIGKILL the postmaster, postmaster.pid remains, and I must kill stray
> backends before restarting. The postmaster should not remove postmaster.pid
> unless it has verified that its children have exited.
This makes sense, however..
> Concretely, that means
> not removing postmaster.pid on immediate shutdown in 9.3 and earlier. That's
> consistent with the rough nature of an immediate shutdown, anyway.
I don't like leaving the postmaster.pid file around, even on an
immediate shutdown. I don't have any great suggestions regarding what
to do, given what we try to do wrt 'immediate', so perhaps it's
acceptable for future releases.
> I'm thinking to preserve postmaster.pid at immediate shutdown in all released
> versions, but I'm less sure about back-patching a change to make
> PGSharedMemoryCreate() pickier. On the one hand, allowing startup to proceed
> with backends still active in the same data directory is a corruption hazard.
The corruption risk, imv anyway, is sufficient to backpatch the change
and overrides the concerns around very fast shutdown/restarts.
Thanks,
Stephen
Attachments:
[application/pgp-signature] signature.asc (197B, ../20130911153200.GD2706@tamriel.snowman.net/2-signature.asc)
download
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: sfrost@snowman.net, noah@leadboat.com
Subject: Re: Weaker shmem interlock w/o postmaster.pid
In-Reply-To: <20130911153200.GD2706@tamriel.snowman.net>
* 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