Re: Weaker shmem interlock w/o postmaster.pid

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Noah Misch <noah(at)leadboat(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Weaker shmem interlock w/o postmaster.pid
Date: 2014-02-12 23:06:40
Message-ID: 20140212230640.GB4831@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Sep 11, 2013 at 02:10:45PM -0400, Robert Haas wrote:
> On Tue, Sep 10, 2013 at 11:33 PM, Noah Misch <noah(at)leadboat(dot)com> wrote:
> > 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.
> > On the other hand, it could break weird shutdown/restart patterns that permit
> > trivial lifespan overlap between backends of different postmasters. Opinions?
>
> I'm more sanguine about the second change than the first. Leaving
> postmaster.pid around seems like a clear user-visible behavior change
> that could break user scripts or have other consequences that we don't
> foresee; thus, I would vote against back-patching it. Indeed, I'm not
> sure it's a good idea to do that even in master. On the other hand,
> tightening the checks in PGSharedMemoryCreate() seems very much worth
> doing, and I think it might also be safe enough to back-patch.

Were these changes every applied? I don't see them.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Craig Ringer 2014-02-12 23:12:44 Re: narwhal and PGDLLIMPORT
Previous Message Marti Raudsepp 2014-02-12 21:54:08 Re: PoC: Partial sort