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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [GENERAL] 8.1.4 - problem with PITR - .backup.done / backup.ready version of the same file at the same time.
Дата
Msg-id 14662.1149017935@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [GENERAL] 8.1.4 - problem with PITR - .backup.done /  (Rafael Martinez <r.m.guerrero@usit.uio.no>)
Ответы Re: [GENERAL] 8.1.4 - problem with PITR - .backup.done /
Список 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 по дате отправления:

Предыдущее
От: Joachim Wieland
Дата:
Сообщение: Re: timezones to own config file
Следующее
От: Mandy Abrahams
Дата:
Сообщение: Looking for Postgres Developers to fix problem