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  (Nitin Jadhav <nitinjadhavpostgres@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [bug?] Missed parallel safety checks, and wrong parallel safety
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Race condition in recovery?