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

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: 8.3 .4 + Vista + MingW + initdb = ACCESS_DENIED
Дата
Msg-id 48F62A07.5050003@hagander.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  (Andrew Chernow <ac@esilo.com>)
Список 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 по дате отправления:

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