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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
