Re: Allow some recovery parameters to be changed with reload

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
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


> 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

In response to


Browse pgsql-hackers by date

  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