Re: Changing recovery.conf parameters into GUCs

On 5 July 2013 19:49, Josh Berkus <josh@agliodbs.com> wrote:
> Robert, Simon, All,
>
> On 04/01/2013 04:51 AM, Robert Haas wrote:> On Thu, Mar 28, 2013 at
> 11:48 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>>> a)  recovery parameters are made into GUCs (for which we have a patch
>>> from Fujii)
>>> b)  all processes automatically read recovery.conf as the last step in
>>> reading configuration files, if it exists, even if data_directory
>>> parameter is in use (attached patch)
>>> c)  we trigger archive recovery by the presence of either
>>> recovery.conf or recovery.trigger in the data directory. At the end,
>>> we rename to recovery.done just as we do now. This means that any
>>> parameters put into recovery.conf will not be re-read when we SIGHUP
>>> after end of recovery. Note that recovery.trigger will NOT be read for
>>> parameters and is assumed to be zero-length.
>>> (minor patch required)
>>
>> I still prefer Greg Smith's proposal.
>>
>> http://www.postgresql.org/message-id/4EE91248.8010505@2ndQuadrant.com
>
> So, this seems to still be stalled.  Is there a way forward on this
> which won't cause us to wait *another* version before we have working
> replication GUCs?

This needs to be broken down rather than just say "I like Greg's
proposal", or I have written a patch. Writing the patch is not the/an
issue.

Greg's points were these (I have numbered them and named/characterised them)

1. MOVE SETTINGS
All settings move into the postgresql.conf.

Comment: AFAIK, all agree this.

2. RELOCATE RECOVERY PARAMETER FILE(s)
As of 9.2, relocating the postgresql.conf means there are no user
writable files needed in the data directory.

Comment: AFAIK, all except Heikki wanted this. He has very strong
objections to my commit that would have allowed relocating
recovery.conf outside of the data directory. By which he means both
the concepts of triggerring replication and of specifying parameters.
Changes in 9.3 specifically write files to the data directory that
expect this.

3. SEPARATE TRIGGER FILE
Creating a standby.enabled file in the directory that houses the
postgresql.conf (same logic as "include" uses to locate things) puts the
system into recovery mode.  That feature needs to save some state, and
making those decisions based on existence of a file is already a thing
we do.  Rather than emulating the rename to recovery.done that happens
now, the server can just delete it, to keep from incorrectly returning
to a state it's exited.  A UI along the lines of the promote one,
allowing "pg_ctl standby", should fall out of here.  I think this is
enough that people who just want to use replication features need never
hear about this file at all, at least during the important to simplify
first run through.

Comment: AFAIK, all except Heikki are OK with this.

4. DISALLOW PREVIOUS API
If startup finds a recovery.conf file where it used to live at,
abort--someone is expecting the old behavior.  Hint to RTFM or include a
short migration guide right on the spot.  That can have a nice section
about how you might use the various postgresql.conf include* features if
they want to continue managing those files separately.  Example: rename
it as replication.conf and use include_if_exists if you want to be able
to rename it to recovery.done like before.  Or drop it into a conf.d
directory where the rename will make it then skipped.

Comment: I am against this. Tool vendors are not the problem here.
There is no good reason to just break everybody's scripts with no
warning of future deprecataion and an alternate API, especially since
we now allow multiple parameter files.

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