From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Greg Smith <greg(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: unite recovery.conf and postgresql.conf |
Date: | 2011-12-14 21:47:12 |
Message-ID: | CABUevEybyde=99Nx1f4bfpYHQT5QvGt3M1NP=i7+qX4XiRrC4A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Dec 14, 2011 at 22:16, Greg Smith <greg(at)2ndquadrant(dot)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/
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2011-12-14 21:57:50 | Re: unite recovery.conf and postgresql.conf |
Previous Message | Andrew Dunstan | 2011-12-14 21:46:58 | Re: pgsql: plpython: Add SPI cursor support |