Re: Feature: POSIX Shared memory support - Mailing list pgsql-patches

On Wed, Feb 07, 2007 at 09:40:16AM -0500, Tom Lane wrote:
> Magnus Hagander <magnus@hagander.net> writes:
> > On Tue, Feb 06, 2007 at 11:08:51PM -0500, Tom Lane wrote:
> >> AFAIK the Windows port is simply wrong/insecure on this point --- it's
> >> one of the reasons you'll never see me recommending Windows as the OS
> >> for a production Postgres server.
>
> > What exactly is the failure case? Might be able to figure out a way to
> > do what we want on win32 even if it's not possible to do it exactly with
> > the sysv semantics.
>
> kill -9 postmaster (only), then try to start new postmaster.  This
> should succeed if and only if there are no live orphaned backends.
> An implementation that hasn't got a direct test for the presence of
> backends can only get one of the two cases correct.
>
> On Windows (or really any EXEC_BACKEND platform) there's an additional
> problem, which is that even with an attach count you have a race
> condition: what if the postmaster launched a new backend just before
> dying, and that process has not yet re-attached to shared memory?
> I don't think this is a big problem in practice, because most people
> don't feel a need for an automated postmaster-restarting monitor, and
> so the time scale for human intervention is too long to hit the race
> condition.  But it's annoying from a theoretical perspective.
>
> It's probably possible to replace the attach-count test with some sort
> of file locking convention --- eg if all the backends hold some type of
> shared lock on postmaster.pid.  This seems unlikely to be much more
> portable than the attach-count solution as far as Unixen go, but if
> we're looking for a Windows-specific solution that's where I'd look.

Ok. From what I can tell, we create a shared mem segment named
PostgreSQL.5432001. If I kill postmaster with something active, and
start a new one, it gets named PostgreSQL.5432002.

If we just didn't add the serial number at the end, then it would be
impossible to create a shared memory segment for the same port again.
That protects the port and not the datadir. But what if we change the
name of the shared memory segment to be that of the data directory
instead of the port?

On win32 we do not have the problem of "orphaned segments", because once
the last process that holds a segment dies, the segment always goes
away. An anonymous region cannot exist if there are no handles open to
it.

As for the EXEC_BACKEND case you mentioned,  don't think it's an issue
on win32. If the postmaster dies before the backend re-attaches, the
backend will fail to re-attach. I think?

Thoughts?

//Magnus