| 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/bt@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| 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:
> 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.
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..
--
Michael
| 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 |