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
|
Список | 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 по дате отправления: