| From: | "Bossart, Nathan" <bossartn(at)amazon(dot)com> |
|---|---|
| To: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, "k(dot)jamison(at)fujitsu(dot)com" <k(dot)jamison(at)fujitsu(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Nitin Jadhav <nitinjadhavpostgres(at)gmail(dot)com> |
| Subject: | Re: please update ps display for recovery checkpoint |
| Date: | 2021-06-07 16:02:03 |
| Message-ID: | 32B59582-AA6C-4609-B08F-2256A271F7A5@amazon.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 6/6/21, 7:14 PM, "Justin Pryzby" <pryzby(at)telsasoft(dot)com> wrote:
> Now, I wonder whether the startup process should also include some detail about
> "syncing data dir". It's possible to strace the process to see what it's
> doing, but most DBA would probably not know that, and it's helpful to know the
> status of recovery and what part of recovery is slow: sync, replay, or
> checkpoint. commit df9274adf improved the situation between replay and
> ckpoint, but it's still not clear what "postgres: startup" means before replay
> starts.
I've seen a few functions cause lengthy startups, including
SyncDataDirectory() (for which I was grateful to see 61752afb),
StartupReorderBuffer(), and RemovePgTempFiles(). I like the idea of
adding additional information in the ps title, but I also think it is
worth exploring additional ways to improve on these O(n) startup
tasks.
Nathan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2021-06-07 17:28:06 | Re: please update ps display for recovery checkpoint |
| Previous Message | Julien Rouhaud | 2021-06-07 15:56:46 | Re: SQL-standard function body |