Re: unite recovery.conf and postgresql.conf

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

Fujii proposes we allow parameters currently in recovery.conf to be
specified in postgresql.conf. All agree to that. Fujii suggests that
if we have both postgresql.conf and recovery.conf then recovery.conf
should contain overrides.

Fujii then suggests that if such an override exists, then SHOW would
not work properly. Magnus is rightly horrified and many speak against
allowing recovery.conf to continue to exist for this reason. I note
that if recovery.conf is an include file of postgresql.conf then the
overrides would work correctly, just as if postgresql.conf had
multiple settings for that parameter. So the premise is incorrect, so
the conclusion is not relevant.

Simon, JD, Greg Stark speak in favour of the usefulness of having a
recovery.conf separate from postgresql.conf. Tatsuo confirms pgpool
uses this.

Simon, Fujii, Peter agree an automatic include of recovery.conf would be useful

Robert points out that pg_ctl promote was a good feature

Simon, JD say that backwards compatibility is important

Everybody agrees a neater way of invoking standby mode would be good.

Peter points out that including recovery target parameters in
postgresql.conf would be difficult and require manual editing, and
also that pg_ctl -o is not a suitable interface.

The thread also includes a variety of other alternate ideas,
misunderstandings and other commentary.

- - -

My thoughts on how to resolve this are...

Everybody agrees these two points:

* Allow recovery parameters to be handled same way as other GUCs, and
specified in postgresql.conf if desired.

* Allow parameters to be reloaded at SIGHUP and visible using SHOW.

Those two things do not themselves force us to break backwards compatibility.

We also agree that we want a neater way to startup in standby mode.

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

In 9.2 the presence of recovery.conf can and therefore should continue
to act as it does in 9.1. This should be automatically included at the
end of postgresql.conf, which naturally and with no additional code
allows us to override settings, with overrides visible by SHOW. We
don't make any specific checks to see if someone has added a
postgresql.conf parameter in there. If there is a recovery target
parameter in recovery.conf we enter recovery, otherwise we operate as
a standby. recovery.conf is no longer *required* for standby modes.

These things are announced as deprecated and will be removed when we
go to release 10.0
* trigger_file
* standby_mode
* recovery.conf indicates standby

recovery.conf should continue to be required to perform a PITR. If we
place the recovery_target parameters into postgresql.conf we will have
no way to differentiate between (1) a recovery that has successfully
completed then crashed and (2) a user-specified recovery, which was
the original rationale for its use. This is OK, since we now encourage
people to enter a recovery by creating recovery.conf and for entering
a standby to use a new cleaner API without the confusing use of the
word "recovery".

I think that meets all requirements, as far as technically possible.

Best Regards

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