From: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> |
---|---|
To: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
Cc: | hamid(dot)akhtar(at)gmail(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org, masao(dot)fujii(at)gmail(dot)com |
Subject: | Re: Should we remove a fallback promotion? take 2 |
Date: | 2020-06-03 10:20:47 |
Message-ID: | 9fdd994d-a531-a52b-7906-e1cc22701310@oss.nttdata.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2020/06/03 12:06, Kyotaro Horiguchi wrote:
> At Wed, 3 Jun 2020 09:43:17 +0900, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> wrote in
>> I will change the status back to Needs Review.
Thanks for the review!
> record = ReadCheckpointRecord(xlogreader, checkPointLoc, 1, false);
> if (record != NULL)
> {
> - fast_promoted = true;
> + promoted = true;
>
> Even if we missed the last checkpoint record, we don't give up
> promotion and continue fall-back promotion but the variable "promoted"
> stays false. That is confusiong.
>
> How about changing it to fallback_promotion, or some names with more
> behavior-specific name like immediate_checkpoint_needed?
I like doEndOfRecoveryCkpt or something, but I have no strong opinion
about that flag naming. So I'm ok with immediate_checkpoint_needed
if others also like that, too.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
From | Date | Subject | |
---|---|---|---|
Next Message | vignesh C | 2020-06-03 10:23:24 | Re: Parallel copy |
Previous Message | Andrey Lepikhov | 2020-06-03 10:00:06 | Re: Asynchronous Append on postgres_fdw nodes. |