Re: Proposal for changes to recovery.conf API

On 1/11/17 5:27 AM, Simon Riggs wrote:
> * Renaming primary_* parameters - Currently we use this config setting
> even when connecting to a standby, so the parameter is confusingly
> named, so 10.0 is a good chance to name it correctly. Will submit as
> separate patch.

I don't subscribe to the idea that 10.0 is a better chance to change
something than any other time.

I agree that the naming has become inaccurate, but it still matches the
basic use case (one primary, one standby (heck, standby is also
inaccurate now!)), and I don't recall anyone being confused by this.
Also, it is debatable whether "sender" is better.  Yes, it's a sender,
but sending what and to whom?

> * Directory for signal files was in my understanding a primary goal of
> the patch. I am happy to remove that into a later submission. That
> resolves, for now, the issue with pg_basebackup -R.

I think the issue was that some people didn't want configuration files
in the data directory.  By removing recovery.conf we accomplish that.
Signal/trigger files are not configuration (or at least it's much easier
to argue that), so I think having them in the data directory is fine.

I'm concerned that having signal files somewhere else opens up a bunch
more edge cases that need to be considered.  For example, what if
someone puts a signal file into a temporary directory that is cleared
after a server crash and restart.  That can mess up a bunch of things.

(I think I like trigger better than signal, btw.  A signal is something
asynchronous.)

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services