Re: unite recovery.conf and postgresql.conf

On Mon, Oct 31, 2011 at 7:38 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)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.

> 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.

It makes sense to have a new flag and that is easily created and used.

> Another simple but somewhat restricted approach is to read and set
> all parameters specified in recovery.conf by using PGC_S_OVERRIDE.
> If we do this, those parameters cannot be changed after startup
> even if recovery.conf is renamed. But the problem is that a user also
> cannot change their settings by reloading the configuration files. This is
> obviously a restriction. But it doesn't break any backward compatibility,
> I believe. No? If a user prefers new functionality (i.e., reload recovery
> parameters) rather than the backward compatibility, he/she can specify
> parameters in postgresql.conf. Thought?

No need to create problems.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services