On Wed, Dec 14, 2011 at 22:16, Greg Smith <g...@2ndquadrant.com> wrote: > I've submitted two patches for adding new include features to the > postgresql.conf file. While not quite commit quality yet, I hope everyone > will agree their reviews this week suggest both are close enough that any > number of people could finish them off. Before re-opening this can of > worms, I wanted people to be comfortable that we can expect them to be > available as building blocks before 9.2 development is finished. Both of > those came out of requests from this unification thread, and they're a > helpful part of what I'd like to propose. > > I don't see any path forward here that still expects the recovery.conf file > to function as it used to. The "make replication easy" crowd will > eventually be larger than the pre-9.0 user base, if it isn't already. And > they clearly want no parts of that thing. There's been over a year of > arguing around how to cope with it that will satisfy everyone, so many > messages I couldn't even read them all usefully in our archives and had to > go here: > > http://postgresql.1045698.n5.nabble.com/recovery-conf-location-td2854644.html > http://postgresql.1045698.n5.nabble.com/unite-recovery-conf-and-postgresql-conf-td4785717.html > > I don't think it's possible. What I would propose is a specification based > on forced failure if there's any sign of recovery.conf, combined with the > simplest migration path we can design to ease upgrades from older versions. > I think we can make the transition easy enough. Users and tool vendors can > make relatively simple changes to support 9.2 without changing everything > they're used to just yet--while still being very clear deprecation has > arrived and they should reconsider their approach. Only bug-compatible > levels of backwards compatibility would make this transparent to them, and > there's way too many issues to allow moving forward that way--a forward path > that as far as I can see is desired by the majority of users, and just as > importantly for all of the potential new users we're impacting with the > current mess. > > There's another, perhaps under considered, concern I want to highlight as > well. Tom has repeatedly noted that one of the worst problems here would go > away if the "existence means do recovery" nature of recovery.conf went > elsewhere. And we know some packagers want to separate the necessary to > manipulate configuration files from the database directory, for permissions > and management reasons. As Heikki nicely put it (over a year ago), "You > don't want to give monitoring tools that decide on failover write access to > the data directory". Any information that the user is supplying for the > purpose of specifying things needs to be easy to relocate to a separate > config file area, instead of treating it more like a control file in > $PGDATA. Some chatting this morning with Simon pointed out a second related > concern there, which makes ideas like "specify the path to the recovery.conf > file" infeasible. The data_directory is itself a parameter, so anything > tied to that or a new GUC means that config files specified there we would > need two passes. First identify the data directory, then go back again to > read recovery.conf from somewhere else. And nobody wants to wander that > way. If it doesn't fit cleanly into the existing postgresql.conf parsing, > it's gotta go. > > Here's the rough outline of what I think would work here: > > -All settings move into the postgresql.conf. > > -As of 9.2, relocating the postgresql.conf means there are no user writable > files needed in the data directory. > > -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.
You say "the server can just delete it". But how will this work if the file is *not* in the data directory? If you are on a Debian style system for example, where all these files go in /etc/postgresql - wouldn't that suddenly require the postgres user to have write access in this directory? If it actually has to be the server that modifies the file, I think it *does* make sense for this file to live in the data directory... [cutting lots of good explanations] Other than that consideration, +1 for this proposal. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers