On 26.12.2012 21:55, Josh Berkus wrote:
>
>> 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.
>
> Huh. My experience integrating PostgreSQL with Puppet or SALT
> infrastructures is that they don't understand trigger files, but they do
> understand configuration+restart/reload. Before we get off on an
> argument about which is better, though, here's an important question:
> how difficult would it be to make the trigger file optional, but still
> effective?
>
> That is, I personally don't care if other people use trigger files, I
> just hate to be forced to use them myself. Is it possible to support
> both options without making either the code or the API hopelessly
> confusing?
There already are two ways to promote a server out of recovery. One is
creating the trigger file. The other is "pg_ctl promote". (it uses a
trigger file called $PGDATA/promote internally, but that's invisible to
the user).
- Heikki