On 2017-04-17 17:28, Tom Lane 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
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
--
Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
