Re: pg_wal/RECOVERYHISTORY file remains after archive recovery

Поиск
Список
Период
Сортировка
От Fujii Masao
Тема Re: pg_wal/RECOVERYHISTORY file remains after archive recovery
Дата
Msg-id CAHGQGwGuDEZXOdW4U9jZPdN82O+0zxxO3EzMq6g-5=WPCKiY-Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_wal/RECOVERYHISTORY file remains after archive recovery  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: pg_wal/RECOVERYHISTORY file remains after archive recovery  (Masahiko Sawada <sawada.mshk@gmail.com>)
Список pgsql-hackers
On Fri, Sep 27, 2019 at 7:16 PM Michael Paquier <michael@paquier.xyz> wrote:
>
> 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.

Ok, I have no objection to remove them just after writeTimeLineHistory().

Regards,

-- 
Fujii Masao



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

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: PATCH: logical_work_mem and logical streaming of largein-progress transactions
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: pglz performance