Re: Changing recovery.conf parameters into GUCs

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.8090500@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 greg(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com