Date: Tue, 13 Sep 2022 17:39:55 -0500
From: Justin Pryzby <pryzby@telsasoft.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Thomas Munro <thomas.munro@gmail.com>,
	Robert Haas <robertmhaas@gmail.com>,
	Aleksander Alekseev <aleksander@timescale.com>,
	pgsql-hackers@lists.postgresql.org
Subject: Re: Background writer and checkpointer in crash recovery
Message-ID: <20220913223954.GU31833@telsasoft.com>
References: 
 <CA+hUKGKBngNkTLm1gSmosY6o-azfUvQxALaBSEOjs6KpKYQ9pg@mail.gmail.com>
 <162763450191.31964.15384962987091520173.pgcf@coridan.postgresql.org>
 <CA+Tgmoa9TsiRDQnTm20fMJjWD3W9Lm3kSS8VJJRXeFnoRw6k9g@mail.gmail.com>
 <CA+hUKGKiBnK9cB_NAxBOHJ7okw9p46F7ZmBP2FjpdTf5RJxS-g@mail.gmail.com>
 <CA+TgmoYxi_f14WW6osP61DYQinrVQLyFX1F38NZWHW9xJJmgNg@mail.gmail.com>
 <CA+hUKG+egXmO5GYhrhO5WgXziFeVMAE_uSVBEEBqsYh3Tid9fg@mail.gmail.com>
 <CA+hUKGK--es4iccyAcLrevOdz5Sns4u=nNXDG5nF_G3MaGPggg@mail.gmail.com>
 <20220912005443.GB31833@telsasoft.com>
 <20220913021311.GN31833@telsasoft.com>
 <YyAHy4UrE1YeY/bt@paquier.xyz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <YyAHy4UrE1YeY/bt@paquier.xyz>
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: 
 <https://www.postgresql.org/message-id/20220913223954.GU31833%40telsasoft.com>
Precedence: bulk

On Tue, Sep 13, 2022 at 01:32:11PM +0900, Michael Paquier wrote:
> On Mon, Sep 12, 2022 at 09:13:11PM -0500, Justin Pryzby wrote:
> > Like this, maybe.
> > 
> > It's similar to what I suggested to consider backpatching here:
> > https://www.postgresql.org/message-id/20201214032224.GA30237%40telsasoft.com
> 
> At the same time, df9274adf has been done because the end-of-recovery
> checkpoint done potentially by the startup process if the checkpointer
> was not up at the end of recovery would take long.  Any of the actions
> taken in the startup process when finishing recovery are not that
> costly, on the contrary, as far as I know.

Your interpretation may be a bit different from mine.

The central problem for me was that the startup process said "recovering
NNN" after it was done recovering NNN.

To fix that, df9274adf took the approach of overwriting the existing PS
with "end-of-recovery checkpoint", which also adds some extra value...

> I am not opposed to clearing the ps display when we are at this state
> of the game for the startup process, but rather than clearing it we
> could switch provide something more useful that shows what's
> happening.  Say a simple "performing end-of-recovery actions", for
> example..

...but the minimal solution (which 2 years ago I suggested could've been
backpatched) is to *clear* the PS (in master branch at the time, that
would've been before also changing it to say stuff about the
checkpoint).

If we'd done that, I probably wouldn't be griping about it now, so my
preference is to *clear* the display as soon as the WAL processing is
done; further overwriting it with additional stuff can be left as a
future enhancement (like "syncing FS" that I brought up last year, and
maybe everything else that calls ereport_startup_progress()).