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    g...@2ndquadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to