|From:||Michael Paquier <michael(at)paquier(dot)xyz>|
|To:||TAKATSUKA Haruka <harukat(at)sraoss(dot)co(dot)jp>|
|Subject:||Re: BUG #15402: Hot standby server with archive_mode=on keeps initial WAL segments|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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. 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
Takatsuka-san, what do you think?
|Next Message||Madeleine Thompson||2018-09-27 05:12:23||Re: BUG #15307: Low numerical precision of (Co-) Variance|
|Previous Message||Michael Paquier||2018-09-27 03:11:34||Re: BUG #15238: Sequence owner not updated when owning table is foreign|