Re: unite recovery.conf and postgresql.conf - Mailing list pgsql-hackers

On 12/14/2011 08:56 PM, Josh Berkus wrote:
> So for streaming replication, will I need to have a standby.enabled
> file, or will there be a parameter in postgresql.conf (or included
> files) which controls whether or not that server is a standby, available?
>
> In the best of all possible worlds, I'd really like to have a GUC which
> 100% controls whether or not the current server is a standby

You keep asking the hard questions.  Right now, I kind of like that it's 
possible to copy a postgresql.conf file from master to standby and just 
use it.  That should still be possible with the realignment into GUCs:

-"standby_mode = on":  Ignored unless you've started the server with 
standby.enabled, won't bother the master if you include it.
-"primary_conninfo":  This will look funny on the master showing it 
connecting to itself, but it will get ignored there too.

I was hoping to just copy over a base backup, "pg_ctl standby" creates 
the needed file and starts the server, and I'm done.  Isn't that the 
easiest replication "hello, world" possible here?  If you think there's 
an easier way here, please describe it more; I'm missing it so far.

Some settings will look a bit weird in the identical postgresql.conf in 
this case, but it think it can be made to work.  Now, eventually you 
will have to sort this out, but my normal principle here is that any 
issue deferred until after people have a working system is automatically 
easier for them to stomach.  Yes there's complexity, but people are 
facing it after the happy dance when the standby works for the first 
time.  The unavoidable bad situation happens if you promote a standby 
made this way.  Replicating more standbys from it won't work; you have 
to fix primary_conninfo at some point.  But once you're the master, you 
should be able to change primary_conninfo anytime--even if you SIGHUP to 
reload, it will now be ignored--so sorting that out doesn't even require 
a server restart.  [Problem of how exactly to define a GUC with those 
properties while also doing the right thing when you are a standby was 
noted then snuck by quietly]

If that is replaced with an edit to the postgresql.conf, that makes the 
bar for setting up a standby higher in my mind.  Now we have every 
clusterware product forced into the position pgpool already finds 
itself, where it needs to cope with making at least one change to that 
file.  I can see a middle ground position where you can have the 
standby.enabled file, but you can also set something in the 
postgresql.conf, but now we're back to conflict and order resolution 
madness.  [See:  "which of postgresql.conf and recovery.conf should be 
read first?"]

[Crazy talk begins here, but without further abuse of parenthetical 
brackets]

There is a route this way I wouldn't mind wandering down, but it circles 
back to one of the even bigger debates.  I would be perfectly happy 
fully embracing multiple configuration files for the server by default 
on every install.  Then the things that vary depending on current role 
can all be put into one place, with some expected splits along this 
line.  Put all the stuff related to standby configuration in one file; 
then tools can know "I can overwrite this whole file" and that will be true.

There's an obvious objection here that "having this crap in two files is 
the problem we're trying to eliminate!"  I would still see this as 
forward, because at the very minimum that split should refactor the 
replication and recovery target pieces into different files.  Different 
tools will want to feel they "own" them and can rewrite them, and making 
that easy should be a major goal.  Also, it will be possible to 
rearrange them if you'd like in whatever order makes sense, which you 
can't do now for the recovery.conf part.  You'd just be breaking tools 
that might expect the default split doing that; if you don't care, have 
at it.

Wandering any distance down that whole road surely stretches the premise 
of "simple migration procedure using include" too far to be true 
anymore.  I was thinking that for 9.2, it seems feasible to get much of 
this legacy stuff sorted better (from the perspective of the person 
focused on simple replication), and add some enabling features.  No 
recovery.conf, everything is a GUC, migration path isn't so bad, people 
get exposed to new concepts for include file organization.  I'd like to 
do some bigger reorganization too, but that seems too much change to 
shove all into one release.  There's a simple path from there that leads 
to both easier tools all around and SET PERSISTENT, and it comes with a 
pile of disruption so big I could throw in "standby controls are now 
100% GUC" for you plus a unicorn and it would slip right by unnoticed.  
That's a tough roadmap to sell unless those promised benefits are proven 
first though.  And I'm thinking a release doing all that is going to 
want to be named 10.0--and what I could really use is a nice, solid 9.2 
that doesn't scare enterprises with too much change next.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us