Re: 8.3 .4 + Vista + MingW + initdb = ACCESS_DENIED

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: 8.3 .4 + Vista + MingW + initdb = ACCESS_DENIED
Дата
Msg-id 48F61FE6.5000001@dunslane.net
обсуждение исходный текст
Ответ на Re: 8.3 .4 + Vista + MingW + initdb = ACCESS_DENIED  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: 8.3 .4 + Vista + MingW + initdb = ACCESS_DENIED  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: 8.3 .4 + Vista + MingW + initdb = ACCESS_DENIED
Следующее
От: Andrew Chernow
Дата:
Сообщение: Re: 8.3 .4 + Vista + MingW + initdb = ACCESS_DENIED