Re: Add checkpoint and redo LSN to LogCheckpointEnd log message - Mailing list pgsql-hackers

From Kyotaro Horiguchi
Subject Re: Add checkpoint and redo LSN to LogCheckpointEnd log message
Date
Msg-id 20220207.101634.205396783432098074.horikyota.ntt@gmail.com
Whole thread Raw
In response to Re: Add checkpoint and redo LSN to LogCheckpointEnd log message  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Responses Re: Add checkpoint and redo LSN to LogCheckpointEnd log message  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
List pgsql-hackers
At Fri, 4 Feb 2022 10:59:04 +0900, Fujii Masao <masao.fujii@oss.nttdata.com> wrote in 
> 
> 
> On 2022/02/03 15:50, Kyotaro Horiguchi wrote:
> > On way to take. In that case should we log something like
> > "Restartpoint canceled" or something?
> 
> +1
> 
> 
> > By the way, restart point should start only while recoverying, and at
> > the timeof the start both checkpoint.redo and checkpoint LSN are
> > already past. We shouldn't update minRecovery point after promotion,
> > but is there any reason for not updating the checkPoint and
> > checkPointCopy?  If we update them after promotion, the
> > which-LSN-to-show problem would be gone.
> 
> I tried to find the reason by reading the past discussion, but have
> not found that yet.
> 
> If we update checkpoint and REDO LSN at pg_control in that case, we
> also need to update min recovery point at pg_control? Otherwise the
> min recovery point at pg_control still indicates the old LSN that
> previous restart point set.

I had an assuption that the reason I think it shouldn't update
minRecoveryPoint is that it has been or is going to be reset to
invalid LSN by promotion and the checkpoint should refrain from
touching it.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: "Jonathan S. Katz"
Date:
Subject: 2022-02-10 release announcement draft
Next
From: Fujii Masao
Date:
Subject: Re: [PATCH] Add min() and max() aggregate functions for xid8