On 2017-04-17 17:28, Tom Lane 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
Such as in my test with pg_switch_xlog(), yes.
> 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.
So, just to be sure, you're saying that when the ".ready" file is
created, it is guaranteed that no process will write to a location
within that segment anymore even if it happens to have the file open?
(That's actually completely obvious, but bear with me, please.)
And further, that each such process will close the open file as soon as
it, intending to write WAL, finds out that the next available location
is not within the file?
Thanks,
--
Christian
