On Mon, Apr 17, 2017 at 5:28 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Christian Ullrich <chris@chrullrich.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.
