Re: pg_wal/RECOVERYHISTORY file remains after archive recovery

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_wal/RECOVERYHISTORY file remains after archive recovery
Date: 2019-09-27 11:41:26
Message-ID: CAHGQGwGuDEZXOdW4U9jZPdN82O+0zxxO3EzMq6g-5=WPCKiY-Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Sep 27, 2019 at 7:16 PM Michael Paquier <michael(at)paquier(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2019-09-27 11:41:35 Re: pglz performance
Previous Message Tomas Vondra 2019-09-27 11:25:20 Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions