On 7/10/13 9:39 AM, Heikki Linnakangas wrote:
On 10.07.2013 02:54, Josh Berkus wrote:
One bit of complexity I'd like to see go away is that we have two
trigger files: one to put a server into replication, and one to promote
it.  The promotion trigger file is a legacy of warm standby, I believe.
  Maybe, now that we have pg_ctl promote available, we can eliminate the
promotion trigger?

No, see http://www.postgresql.org/message-id/5112a54b.8090...@vmware.com.

Right, you had some good points in there. STONITH is so hard already, we need to be careful about eliminating options there.

All the summaries added here have actually managed to revive this one usefully early in the release cycle! Well done. I just tried to apply Michael's 20130325_recovery_guc_v3.patch and the bit rot isn't that bad either. 5 rejection files, nothing big in them.

The only overlap between the recovery.conf GUC work and refactoring the trigger file is that the trigger file is referenced in there, and we really need to point it somewhere to be most useful.

Personally, I don't care if we support the old recovery.conf-trigger
behavior as long as I'm not forced to use it.

If you accept Heikki's argument for why the file can't go away altogether, and it's pretty reasonable, I think two changes reach a point where everyone can live with this:

-We need a useful default filename for trigger_file to point at.
-"pg_ctl failover" creates that file.

As for the location to default to, the pg_standby docs suggest /tmp/pgsql.trigger.5432 while the "Binary Replication Tutorial" on the wiki uses a RedHat directory layout $PGDATA/failover

The main reason I've preferred something in the data directory is that triggering a standby is too catastrophic for me to be comfortable putting it in /tmp. Any random hooligan with a shell account can trigger a standby and break its replication. Putting the unix socket into /tmp only works because the server creates the file as part of startup. Here that's not possible, because creating the trigger is the signalling mechanism.

I don't think there needs to be a CLI interface for putting the alternate possible text into the trigger--that you can ask for 'fast' startup. It's nice to have available as an expert, but it's fine for that to be harder to do.

Greg Smith   2ndQuadrant US    g...@2ndquadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to