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?
-- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
