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

From Andrew Dunstan
Subject Re: 8.3 .4 + Vista + MingW + initdb = ACCESS_DENIED
Date
Msg-id 48F61FE6.5000001@dunslane.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
List pgsql-hackers

Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>   
>> I have verified that it does indeed work. Underneath the hood it uses 
>> the native call LockFileEx() see win32io.c in Perl source. I suggest we 
>> should switch from this flaky use of Global namespace to having the 
>> postmaster acquire an explicit lock on a file in the datadir.
>>     
>
> That can only be a solution if postmaster child processes will inherit
> the lock.  (The nasty scenario is where the postmaster has died but one
> or more backends are still alive --- a new postmaster attempting to
> start MUST detect that and refuse to start.)  Does fork/exec preserve
> lock ownership on Windows?
>
>             
>   

I don't think so, no. But we could have the children explicitly acquire 
a shared lock, so if the postmaster at startup tried to grab an 
exclusive lock that would fail if any child were still alive.

cheers

andrew


pgsql-hackers by date:

Previous
From: Andrew Dunstan
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