| From: | Josh Berkus <josh(at)agliodbs(dot)com> |
|---|---|
| To: | Robert Treat <rob(at)xzilla(dot)net> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Feature Request: pg_replication_master() |
| Date: | 2012-12-26 19:55:10 |
| Message-ID: | 50DB561E.4010106@agliodbs.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2012-12-26 20:04:10 | Re: Feature Request: pg_replication_master() |
| Previous Message | Greg Smith | 2012-12-26 19:37:45 | Re: buffer assertion tripping under repeat pgbench load |