On Mon, Dec 24, 2012 at 7:04 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Josh Berkus <josh@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