From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
---|---|
To: | masao(dot)fujii(at)oss(dot)nttdata(dot)com |
Cc: | andres(at)anarazel(dot)de, alvherre(at)2ndquadrant(dot)com, michael(at)paquier(dot)xyz, robertmhaas(at)gmail(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Remove non-fast promotion Re: Should we remove a fallback promotion? take 2 |
Date: | 2020-04-22 00:13:06 |
Message-ID: | 20200422.091306.1808979581640403999.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At Tue, 21 Apr 2020 22:08:56 +0900, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> wrote in
>
>
> On 2020/04/21 17:15, Kyotaro Horiguchi wrote:
> > At Mon, 20 Apr 2020 15:26:16 +0900, Fujii Masao
> > <masao(dot)fujii(at)oss(dot)nttdata(dot)com> wrote in
> >> Patch attached. I will add this into the first CF for v14.
> > - if (!fast_promoted)
> > + if (!promoted)
> > RequestCheckpoint(CHECKPOINT_END_OF_RECOVERY |
> > CHECKPOINT_IMMEDIATE |
> > CHECKPOINT_WAIT);
> > If we don't find the checkpoint record just before, we don't insert
> > End-Of-Recovery record then run an immediate chekpoint. I think if we
> > nuke the non-fast promotion, shouldn't we insert the EOR record even
> > in that case?
>
> I'm not sure if that's safe. What if the server crashes before the
> checkpoint
> completes in that case? Since the last checkpoint record is not
> available,
> the subsequent crash recovery will fail. This would lead to that the
> server
> will never start up. Right? Currently ISTM that
Yes, that's right.
> end-of-recovery-checkpoint
> is executed to avoid such trouble in that case.
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.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro Horiguchi | 2020-04-22 00:13:47 | Re: forgotten initalization of a variable |
Previous Message | Alvaro Herrera | 2020-04-21 23:56:36 | Re: ALTER TABLE ... SET STORAGE does not propagate to indexes |