Re: 8.3 .4 + Vista + MingW + initdb = ACCESS_DENIED - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: 8.3 .4 + Vista + MingW + initdb = ACCESS_DENIED
Date
Msg-id 48F62A07.5050003@hagander.net
Whole thread Raw
In response to Re: 8.3 .4 + Vista + MingW + initdb = ACCESS_DENIED  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: 8.3 .4 + Vista + MingW + initdb = ACCESS_DENIED  (Andrew Chernow <ac@esilo.com>)
List pgsql-hackers
Tom Lane wrote:
> Andrew Chernow <ac@esilo.com> writes:
>> Tom Lane wrote:
>>> Does fork/exec preserve lock ownership on Windows?
> 
>> Not to my knowledge.  On windows, there is only CreateProcess 
>> (http://msdn.microsoft.com/en-us/library/ms682425.aspx).  That doesn't 
>> resemble the behavior of fork or exec at all.
> 
> Hmm.  Now that you mention it, didn't we solve a similar problem by
> exploiting the behavior where CreateProcess creates a process but
> doesn't start it running?  I'm envisioning

Yes, we're doing this to pass certain handles down to it.


>     * Create child process in suspended state
>     * Assign it ownership of a lock (can we do that?)
>     * Set it running
> 
> If the postmaster crashes between steps 1 and 2, then the zombie process
> doesn't hold a lock, but it will never do anything so it doesn't matter.
> 
> OTOH, if the postmaster crashes between steps 2 and 3, there's probably
> no way to restart your database except to reboot ...

Haven't looked through the details (just arrived in Prato), but once the
process dies, the lock will go away. So there shoul dbe no need to
reboot, you just need to get rid of all the running (possibly orphaned)
processes.

//Magnus


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: 8.3 .4 + Vista + MingW + initdb = ACCESS_DENIED
Next
From: Andrew Chernow
Date:
Subject: Re: 8.3 .4 + Vista + MingW + initdb = ACCESS_DENIED