Re: unite recovery.conf and postgresql.conf - Mailing list pgsql-hackers

On Mon, Oct 31, 2011 at 5:23 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On Mon, Oct 31, 2011 at 7:38 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
>
>>> In 9.2 the presence of recovery.conf can and therefore should continue
>>> to act as it does in 9.1.
>>
>> This means that recovery.conf is renamed to recovery.done at the end of
>> recovery. IOW, all settings in recovery.conf are reset when recovery ends.
>> Then if you run "pg_ctl reload" after recovery, you'll get something like
>> the following error message and the reload will always fail;
>>
>>   LOG:  parameter "standby_mode" cannot be changed without restarting
>> the server
>
>> To resolve this issue,
>
> This issue exists whether or not we have recovery.conf etc., so yes,
> we must solve the problem.

No. If we don't have recovery.conf, all parameters exist in postgresql.conf.
The above issue would not occur unless a user makes a mistake, e.g.,
change the value of the parameter which cannot be changed without
the server restart.

>> I think that we need to introduce new GUC flag
>> indicating parameters are used only during recovery, and need to define
>> recovery parameters with that flag. Whenever "pg_ctl reload" is executed,
>> all the processes check whether recovery is in progress, and ignore
>> silently the parameters with that flag if not. I'm not sure how easy we
>> can implement this. In addition to introducing that flag, we might need to
>> change some processes which cannot access to the shared memory so that
>> they can. Otherwise, they cannot know whether recovery is in progress.
>> Or we might need to change them so that they always ignore recovery
>> parameters.
>
> The postmaster knows whether its in recovery or not without checking
> shared memory. Various postmaster states describe this. If not
> postmaster, other backends can run recoveryinprogress() as normal.

AFAIR archiver and syslogger cannot access to the shared memory, i.e.,
they cannot run RecoveryInProgress(). They don't use any recovery
parameters for now, so we can change them so that they always ignore
those parameters. Though I'm not inclined to add the process-specific code
like the following into the GUC mechanism as much as possible.
   if (I am postmaster)   {       if (recovery is NOT in progress)           reset the recovery parameters;   }   else
if(I am archiver or syslogger)       /* always ignore */   else   {       if (recovery is NOT in progress)
resetthe recovery parameters;   } 

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center