Re: Remove non-fast promotion Re: Should we remove a fallbackpromotion? take 2 - Mailing list pgsql-hackers

From Kyotaro Horiguchi
Subject Re: Remove non-fast promotion Re: Should we remove a fallbackpromotion? take 2
Date
Msg-id 20200422.120950.667254551595683133.horikyota.ntt@gmail.com
Whole thread Raw
In response to Re: Remove non-fast promotion Re: Should we remove a fallbackpromotion? take 2  (Fujii Masao <masao.fujii@oss.nttdata.com>)
List pgsql-hackers
At Wed, 22 Apr 2020 11:51:42 +0900, Fujii Masao <masao.fujii@oss.nttdata.com> wrote in 
> > I meant that we always have EOR at the end of recovery.  So in the
> > missing latest checkpoint (and crash recovery) case, we insert EOR
> > after the immediate checkpoint. That also means we no longer set
> > CHECKPOINT_END_OF_RECOVERY to the checkpoint, too.
> 
> Could you tell me what the benefit by this change is? Even with this
> change,
> the server still needs to wait for the checkpoint to complete before
> becoming the master and starting the service, unlike fast
> promotion. No?

There's no benefit of performance.  It's just for simplicity by
signalling end-of-recovery in a unified way.

Long ago, we had only non-fast promotion, which is marked by
CHECKPOINT_END_OF_RECOVERY.  When we introduced fast-promotion, it is
marked by the END_OF_RECOVERY record since checkpoint record is not
inserted at the promotion time. However, we internally fall back to
non-fast promotion when we need to make a checkpoint immediately.
If we remove non-fast checkpoint, we don't need two means to signal
end-of-recovery.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Remove non-fast promotion Re: Should we remove a fallbackpromotion? take 2
Next
From: David Rowley
Date:
Subject: Re: Parallel Append can break run-time partition pruning