On Mon, Apr 17, 2017 at 5:28 PM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote:
Christian Ullrich <chris@xxxxxxxxxxxxxx> 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?)
