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()).
