Re: please update ps display for recovery checkpoint
От | Justin Pryzby |
---|---|
Тема | Re: please update ps display for recovery checkpoint |
Дата | |
Msg-id | 20210607021348.GA14099@telsasoft.com обсуждение исходный текст |
Ответ на | Re: please update ps display for recovery checkpoint (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: please update ps display for recovery checkpoint
Re: please update ps display for recovery checkpoint |
Список | pgsql-hackers |
On Mon, Dec 14, 2020 at 12:01:33PM +0900, Michael Paquier wrote: > On Sat, Dec 12, 2020 at 12:41:25AM +0000, Bossart, Nathan wrote: > > On 12/11/20, 4:00 PM, "Michael Paquier" <michael@paquier.xyz> wrote: > >> My counter-proposal is like the attached, with the set/reset part not > >> reversed this time, and the code indented :p > > > > Haha. LGTM. > > Thanks. I have applied this one, then. To refresh: commit df9274adf adds "checkpoint" info to "ps", which previously continued to say "recovering NNNNN" even after finishing WAL replay, and throughout the checkpoint. 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. There's some interaction between Thomas' commit 61752afb2 and recovery_init_sync_method - if we include a startup message, it should distinguish between "syncing data dirs (fsync)" and (syncfs). Putting this into fd.c seems to assume that we can clobber "ps", which is fine when called by StartupXLOG(), but it's a public interface, so I'm not sure if it's okay to assume that's the only caller. Maybe it should check if MyAuxProcType == B_STARTUP. -- Justin
Вложения
В списке pgsql-hackers по дате отправления: