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.eisentr...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
