Re: Why does the WAL writer sit on completed segments (on Windows)?

On Mon, Apr 17, 2017 at 5:28 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Christian Ullrich <chris(at)chrullrich(dot)net> writes:
> > The reason, as Process Monitor shows, is that the WAL writer process
> > keeps the file open for about one second after the
> > archive_status\*.ready file has been created. The archiver runs the
> > archive_command "too early", resulting in the sharing [1] violation seen
> > above.
>
> I'm not sure why that happens, but even if we changed the logic inside
> walwriter to avoid it, you'd still need to adapt your archiving script
> to deal with the case. The reason is that the walwriter isn't necessarily
> the only process writing WAL --- regular backends do it too, depending on
> timing. In such a case a backend would be holding an open-file reference
> until the next time it tries to write WAL, which might be awhile. It's
> not really practical to change that behavior; we certainly wouldn't want
> to open and close WAL files for every write.
>

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?)

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>