Re: pg_wal/RECOVERYHISTORY file remains after archive recovery

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: pg_wal/RECOVERYHISTORY file remains after archive recovery
Дата
Msg-id 20190927101458.GA25213@paquier.xyz
обсуждение исходный текст
Ответ на Re: pg_wal/RECOVERYHISTORY file remains after archive recovery  (Fujii Masao <masao.fujii@gmail.com>)
Ответы Re: pg_wal/RECOVERYHISTORY file remains after archive recovery  (Fujii Masao <masao.fujii@gmail.com>)
Список pgsql-hackers
On Fri, Sep 27, 2019 at 05:58:21PM +0900, Fujii Masao wrote:
> So you think that it's better to remove them just after writeTimeLineHistory()?
> Per the following Sawada-san's comment, I was thinking that idea is basically
> not good. And, RemoveNonParentXlogFiles() also removes garbage files from
> pg_wal. It's simpler if similar codes exist near. Thought?

Sawada-san's argument of upthread is that it is not good to put
exitArchiveRecovery() after writeTimeLineHIstory(), which is what
cbc55da has done per the reasons mentioned in the commit log, and we
should not change that.

My argument is we know that RECOVERYXLOG and RECOVERYHISTORY are not
needed anymore at this stage of recovery, hence we had better remove
them as soon as possible.  I am not convinced that it is a good idea
to move the cleanup close to RemoveNonParentXlogFiles().  First, this
is an entirely different part of the logic where the startup process
has already switched to a new timeline.  Second, we add more steps
between the moment the two files are not needed and the moment they
are removed, so any failure in-between would cause those files to
still be there (we cannot say either that we will not manipulate this
code later on) and we don't want those files to lie around.  So,
mentioning that we do the cleanup just after writeTimeLineHIstory()
because we don't need them anymore is more consistent with what has
been done for ages for the end of archive recovery, something that
cbc55da unfortunately broke.
--
Michael

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jeevan Ladhe
Дата:
Сообщение: Re: let's kill AtSubStart_Notify
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: PATCH: logical_work_mem and logical streaming of largein-progress transactions