Re: when the startup process doesn't
От | Justin Pryzby |
---|---|
Тема | Re: when the startup process doesn't |
Дата | |
Msg-id | 20210609161918.GY16435@telsasoft.com обсуждение исходный текст |
Ответ на | Re: when the startup process doesn't (Nitin Jadhav <nitinjadhavpostgres@gmail.com>) |
Ответы |
Re: when the startup process doesn't
|
Список | pgsql-hackers |
On Wed, Jun 09, 2021 at 05:09:54PM +0530, Nitin Jadhav wrote: > > + {"log_min_duration_startup_process", PGC_SUSET, LOGGING_WHEN, > > > > I think it should be PGC_SIGHUP, to allow changing it during runtime. > > Obviously it has no effect except during startup, but the change will be > > effective if the current process crashes. > > See also: https://www.postgresql.org/message-id/20210526001359.GE3676@telsasoft.com > > I did not get exactly how it will change behaviour. In my > understanding, when the server restarts after a crash, it fetches the > value from the config file. So if there is any change that gets > affected. Kindly correct me if I am wrong. I don't think so. I checked and SelectConfigFiles is called only once to read config files and cmdline args. And not called on restart_after_crash. The GUC definitely isn't SUSET, since it's not useful to write in a (super) user session SET log_min_duration_startup_process=123. I've triple checked the behavior using a patch I submitted for Thomas' syncfs feature. ALTER SYSTEM recovery_init_sync_method=syncfs was not picked up when I sent SIGABRT. But with my patch, if I also do SELECT pg_reload_conf(), then a future crash uses syncfs. https://www.postgresql.org/message-id/20210526001359.GE3676@telsasoft.com -- Justin
В списке pgsql-hackers по дате отправления: