Re: unite recovery.conf and postgresql.conf

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(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us