Re: unite recovery.conf and postgresql.conf

On Sat, Oct 29, 2011 at 7:54 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On Fri, Sep 9, 2011 at 10:56 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>
>> In previous discussion, we've reached the consensus that we should unite
>> recovery.conf and postgresql.conf. The attached patch does that. The
>> patch is WIP, I'll have to update the document, but if you notice something,
>> please feel free to comment.
>
> My short summary of the thread is

Thanks!

> In 9.1 we added "pg_ctl promote" as a better way of indicating
> failover/switchover. When we did that we kept the trigger_file
> parameter added in 9.0, which shows it is possible to add a new API
> without breaking backwards compatibility.
>
> We should add a "pg_ctl standby" command as a better way of indicating
> starting up (also described as triggering) standby mode. We keep
> standby_mode parameter. There is no difference here between file
> based and stream based replication: you can have file, stream or both
> file and stream (as intended).
> In this mode the recovery target parameters are *ignored* even if
> specified (explained below).
> http://developer.postgresql.org/pgdocs/postgres/recovery-target-settings.html

Agreed to add "pg_ctl standby". I think that this can be committed
separately from the change of recovery.conf.

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

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?

Regards,

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