Re: needless complexity in StartupXLOG - Mailing list pgsql-hackers

From Kyotaro Horiguchi
Subject Re: needless complexity in StartupXLOG
Date
Msg-id 20210728.180429.2208582621621366435.horikyota.ntt@gmail.com
Whole thread Raw
In response to Re: needless complexity in StartupXLOG  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
At Tue, 27 Jul 2021 11:03:14 -0400, Robert Haas <robertmhaas@gmail.com> wrote in 
> On Tue, Jul 27, 2021 at 9:18 AM Kyotaro Horiguchi
> <horikyota.ntt@gmail.com> wrote:
> > FWIW, by the way, I complained that the variable name "promoted" is a
> > bit confusing.  It's old name was fast_promoted, which means that fast
> > promotion is being *requsted* and ongoing.  On the other hand the
> > current name "promoted" still means "(fast=non-fallback) promotion is
> > ongoing" so there was a conversation as the follows.
> >
> > https://www.postgresql.org/message-id/9fdd994d-a531-a52b-7906-e1cc22701310%40oss.nttdata.com
> 
> I agree - that variable name is also not great. I am open to making
> improvements in that area and in others that have been suggested on
> this thread, but my immediate goal is to figure out whether anyone
> objects to me committing the posted patch. If nobody comes up with a
> reason why it's a bad idea in the next few days, I'll plan to move
> ahead with it.

That's fine with me.

I still haven't find a way to lose the last checkpoint due to software
failure.  Repeated promotion without having new checkpoints is safe as
expected. We don't remove WAL files unless a checkpoint completes, and
a checkpoint preserves segments back to the one containing its redo
point.

In short, I'm for it.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: proposal: enhancing plpgsql debug API - returns text value of variable content
Next
From: Nitin Jadhav
Date:
Subject: Re: when the startup process doesn't (logging startup delays)