Re: BUG #15402: Hot standby server with archive_mode=on keeps initial WAL segments

Hi Michael,

On Thu, 27 Sep 2018 13:44:30 +0900
Michael Paquier <michael(at)paquier(dot)xyz> wrote:

> On Wed, Sep 26, 2018 at 02:12:36PM +0900, TAKATSUKA Haruka wrote:
> > I think is it natural that some segments are not archived when you
> > switch archive_mode back-and-forth.
> >
> > I also think a fix to prevent generating .ready file at hot standby
> > server in this case is better. I don't have a concrete idea to do so now.
>
> I looked at this problem, and I completely agree. From what I can see,
> the restart point run on the standby creates a .ready file for the
> oldest segment because there were no .done file present in it, so the
> checkpointer thinks that it should mark the file with .ready, and then
> makes it ready for archiving, which is never going to happen with
> archive_mode = on. All the newer segments are already marked with
> .done, so they are getting recycled correctly.
>
> Your patch is not completely correct though, as the origin of the
> problem comes from XLogArchiveCheckDone(), which should be made more
> solid depending on the archive mode used. The solution attached
> actually fixes a second bug, which is less annoying by the way, as past
> backup history files may stay behind on standbys. I looked at all the
> code paths of XLogArchivingActive() and that's the only problem I can
> see.

I fixed only RemoveOldXlogFiles() in my patch because merely
I wasn't sure that keeping an old history file is a bug behavir.

> In guc.c, SHOW archive_command would print as "(disabled)" on
> standbys even if archive_mode = on, but we lived with this behavior for
> ages. The user can understand that archiving is enabled only on a
> primary this way when looking at a standby, so that should not be
> changed.
>
> Takatsuka-san, what do you think?

I think it is not necessary to change though it is a somewhat
mistakable feature.

Thanks,
Haruka Takatsuka