Re: [HACKERS] Proposal for changes to recovery.conf API

Having already agreed to remove the two mentioned aspects, I'm just
replying to fill in some historical details.

On 11 January 2017 at 17:25, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
> 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?

Sending server is the term already used to describe a server that is
either a master or a relaying standby.

But as already requested, I will remove from patch.

>> * 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.

There were a considerable number of people that pushed to make the
data directory non-user writable, which is where the signal directory
came from.

I can see the argument, but since those that spoke previously have
evaporated, I'm easy.

> 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.

We already have trigger_file as a way to specify an alternate
directory, so if I remove signal_file_directory I will need to replace
trigger_file as a parameter.

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

The code already calls them signal files, its just called trigger externally.

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