On 5 July 2013 19:49, Josh Berkus 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 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

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 15 of 19 | next ›
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedMar 28, '13 at 3:49p
activeJul 15, '13 at 5:42a
posts19
users8
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2017 Grokbase