Re: Allow some recovery parameters to be changed with reload
От | Fujii Masao |
---|---|
Тема | Re: Allow some recovery parameters to be changed with reload |
Дата | |
Msg-id | a136a397-1401-9531-20c1-1b83575fd68d@oss.nttdata.com обсуждение исходный текст |
Ответ на | Re: Allow some recovery parameters to be changed with reload (Sergei Kornilov <sk@zsrv.org>) |
Ответы |
Re: Allow some recovery parameters to be changed with reload
|
Список | pgsql-hackers |
On 2020/11/06 21:36, Sergei Kornilov wrote: > Hello > >> Currently when restore_command is not set, archive recovery fails >> at the beginning. With the patch, how should we treat the case where >> retore_command is reset to empty during archive recovery? We should >> reject that change of restore_command? > > Good point. I think we should reject that change. But (AFAIC) I cannot use GUC check callback for this purpose, as onlythe startup process knows StandbyModeRequested. I think it would be appropriate to call validateRecoveryParameters fromStartupRereadConfig. I don't think this idea is ok because emptying restore_command and the reload of configuration file could cause the server doing archive recovery to shut down with FATAL error. I'm wondering if it's safe to allow restore_command to be emptied during archive recovery. Even when it's emptied, archive recovery can proceed by reading WAL files from pg_wal directory. This is the same behavior as when restore_command is set to, e.g., /bin/false. So maybe we don't need to treat the empty restore_command so special?? OTOH, we should not remove the check of restore_command in validateRecoveryParameters(). Otherwise, when users forget to specify restore_command when starting archive recovery, recovery could wrongly proceed and the database could get corrupted. Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
В списке pgsql-hackers по дате отправления: