Re: [ADMIN] Why does the WAL writer sit on completed segments (on Windows)?
От | Christian Ullrich |
---|---|
Тема | Re: [ADMIN] Why does the WAL writer sit on completed segments (on Windows)? |
Дата | |
Msg-id | c1ab1b4d-fd0a-941c-f59f-58b7dcfb3523@chrullrich.net обсуждение исходный текст |
Ответ на | Re: [ADMIN] Why does the WAL writer sit on completed segments (onWindows)? (Christian Ullrich <chris@chrullrich.net>) |
Список | pgsql-admin |
On 2017-04-17 19:07, Christian Ullrich wrote: > On 2017-04-17 18:55, Tom Lane wrote: > >> Magnus Hagander <magnus@hagander.net> writes: > >>> But all our files are opened with (FILE_SHARE_READ | FILE_SHARE_WRITE | >>> FILE_SHARE_DELETE). So shouldn't this allow 7zip (or whatever) to >>> open up >>> the file, regardless of us holding it open? (Looking at >>> https://msdn.microsoft.com/en-us/library/windows/desktop/aa363874(v=vs.85).aspx >>> >>> at least that's how I read it?) > > No, I'm afraid not. The share modes have to be compatible across all > CreateFile() calls (that result in concurrently open handles). After > Postgres has opened the file with all three share modes, any later calls > must use all three as well. Um, no, not exactly. You can open the file _READ|_WRITE as long as no one else actually has it open for delete (by setting the delete-on-close flag?). And here I thought I understood share modes ... sorry. I just ran through it in procmon again, and with the input redirection, cmd successfully opens it _READ|_WRITE. -- Christian
В списке pgsql-admin по дате отправления: