Re: unite recovery.conf and postgresql.conf - Mailing list pgsql-hackers

On Wed, Dec 14, 2011 at 22:16, Greg Smith <greg@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/