From: | Christian Ullrich <chris(at)chrullrich(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | pgsql-admin <pgsql-admin(at)postgresql(dot)org> |
Subject: | Re: Why does the WAL writer sit on completed segments (on Windows)? |
Date: | 2017-04-17 17:14:13 |
Message-ID: | c1ab1b4d-fd0a-941c-f59f-58b7dcfb3523@chrullrich.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
On 2017-04-17 19:07, Christian Ullrich wrote:
> On 2017-04-17 18:55, Tom Lane wrote:
>
>> Magnus Hagander <magnus(at)hagander(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | M Kiesewetter | 2017-04-18 14:36:07 | Question about pg_xlog |
Previous Message | Christian Ullrich | 2017-04-17 17:07:33 | Re: Why does the WAL writer sit on completed segments (on Windows)? |