Magnus Hagander <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq