On Mon, Dec 24, 2012 at 7:04 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Josh Berkus <j...@agliodbs.com> writes: >>> What the patch doesn't change is the requirement to have a file that >>> causes the server to place itself into archive recovery. So there is >>> no more recovery.conf and instead we have a file called >>> recovery.trigger instead. > >> Requiring a file in order to make a server a replica is what we should >> be trying to get away from. It should be possible to configure a server >> as a replica by setting a GUC in PostgreSQL.conf (before first startup, >> obviously). > > I'm not entirely convinced about that, because if we do it like that, we > will *never*, *ever* be able to store GUC settings except in a flat, > editable textfile. Now, that's fine by me personally, but there seem to > be a lot of people around here with ambitions to bury those settings in > not-so-editable places. Including you, to judge by your next sentence: > >> Naturally, this then links in with SET PERSISTENT or >> however we're calling it these days in order to take a server out of >> replica mode. > > People are going to want to be able to push a server into, and possibly > out of, replica mode without necessarily having the server up at the > time. So I'm not real convinced that we want that flag to be a GUC. > A trigger file is a lot easier to manipulate from places like shell > scripts. >
I'm not sure that my POV exactly matches up with Tom's, but on the last point, I strongly agree that the use of the trigger file makes it trivial to integrate Postgres warm standby management into 3rd party tools. I'm not against coming up with a new API that's better for postgres dedicated tools, but I think you're going to really make it harder for people if you eliminate the trigger file method for coming out of recovery. Robert Treat play: xzilla.net work: omniti.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
