Re: Feature: POSIX Shared memory support

Magnus Hagander <magnus(at)hagander(dot)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.

regards, tom lane