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

From Tom Lane
Subject Re: [GENERAL] 8.1.4 - problem with PITR - .backup.done / backup.ready version of the same file at the same time.
Date
Msg-id 14662.1149017935@sss.pgh.pa.us
Whole thread Raw
In response to Re: [GENERAL] 8.1.4 - problem with PITR - .backup.done /  (Rafael Martinez <r.m.guerrero@usit.uio.no>)
Responses Re: [GENERAL] 8.1.4 - problem with PITR - .backup.done /  (Rafael Martinez <r.m.guerrero@usit.uio.no>)
List pgsql-hackers
Rafael Martinez <r.m.guerrero@usit.uio.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("couldnot rename file \"%s\" to \"%s\": %m",                       rlogready, rlogdone)));
 

If you find any then we might need a different theory ...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Joachim Wieland
Date:
Subject: Re: timezones to own config file
Next
From: Mandy Abrahams
Date:
Subject: Looking for Postgres Developers to fix problem