Re: [GENERAL] 8.1.4 - problem with PITR - .backup.done / backup.ready version of the same file at the same time.

Rafael Martinez <r(dot)m(dot)guerrero(at)usit(dot)uio(dot)no> writes:
> What happens if we have a race condition and the archiver creates
> a .done file between the last check for the .done file and the creation
> of the .ready file by XLogArchiveNotify?

That can't happen; the archiver creates the .done file by rename()ing
the previous .ready file, which is (supposed to be) an atomic action.
If the .ready file isn't there, and then after that we see that the
.done file isn't there, then either neither of them are there or the
filesystem is seriously broken.

My thought is that the stat()s on the .done file failed for some obscure
reason, perhaps insufficient kernel resources, even though the file was
actually there.

If you have postmaster log output for the interval in which this
happened, it would be interesting to look for occurrences of this
warning message from pgarch_archiveDone:

if (rename(rlogready, rlogdone) < 0)
ereport(WARNING,
(errcode_for_file_access(),
errmsg("could not rename file \"%s\" to \"%s\": %m",
rlogready, rlogdone)));

If you find any then we might need a different theory ...

regards, tom lane