Re: Background writer and checkpointer in crash recovery

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Justin Pryzby <pryzby(at)telsasoft(dot)com>
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Aleksander Alekseev <aleksander(at)timescale(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Background writer and checkpointer in crash recovery
Date: 2022-09-13 04:32:11
Message-ID: YyAHy4UrE1YeY/
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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:

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.

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

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Julien Rouhaud 2022-09-13 04:33:16 Re: Query Jumbling for CALL and SET utility statements
Previous Message Michael Paquier 2022-09-13 04:10:36 Re: Assertion failure in WaitForWALToBecomeAvailable state machine