| From: | Sergei Kornilov <sk(at)zsrv(dot)org> |
|---|---|
| To: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, "a(dot)lubennikova(at)postgrespro(dot)ru" <a(dot)lubennikova(at)postgrespro(dot)ru> |
| Cc: | "robertmhaas(at)gmail(dot)com" <robertmhaas(at)gmail(dot)com>, "michael(at)paquier(dot)xyz" <michael(at)paquier(dot)xyz>, "andres(at)anarazel(dot)de" <andres(at)anarazel(dot)de>, "peter(dot)eisentraut(at)2ndquadrant(dot)com" <peter(dot)eisentraut(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Allow some recovery parameters to be changed with reload |
| Date: | 2020-11-06 12:36:48 |
| Message-ID: | 56311604665173@mail.yandex.ru |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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 only the startup process knows StandbyModeRequested. I think it would be appropriate to call validateRecoveryParameters from StartupRereadConfig. As side effect this add warning/hint "specified neither primary_conninfo nor restore_command" in standby mode in appropriate configuration state. Not sure about the rest checks in validateRecoveryParameters, maybe it's a wrong idea to recheck them here and I need to separate these checks into another function.
regards, Sergei
| Attachment | Content-Type | Size |
|---|---|---|
| v2_restore_command_reload.patch | text/x-diff | 3.3 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | John Naylor | 2020-11-06 13:00:52 | Re: Move catalog toast table and index declarations |
| Previous Message | Magnus Hagander | 2020-11-06 12:31:44 | Re: Move OpenSSL random under USE_OPENSSL_RANDOM |