Greg, > You keep asking the hard questions.
I practice. ;-) > 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: ... long discussion omitted here. I agree that GUC vs. standby.enabled is a trade-off. I further agree that where we're going with this eventually is SET PERSISTENT. I feel that Greg's proposal is a substantial improvement on the current arrangement and eliminates *my* #1 source of replication-configuration pain, and we can keep improving it later. I think we need to give some thought as to how this will play out for PITR, since there is far less reason to change the operation of PITR, and much older backup tools which rely on its current operation. Otherwise, +1. > 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. I would love to see a writeup on this someday. Blog? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers