Re: Turning recovery.conf into GUCs

On 1/6/15 12:57 AM, Josh Berkus wrote:
> On 01/05/2015 05:43 PM, Peter Eisentraut wrote:
>> The wins on the other hand are obscure: You can now use SHOW to inspect
>> recovery settings.  You can design your own configuration file include
>> structures to set them.  These are not bad, but is that all?
>
> That's not the only potential win, and it's not small either. I'll be
> able to tell what master a replica is replicating from using via a port
> 5432 connection (currently there is absolutely no way to do this).

That's one particular case of what I mentioned above under using SHOW to
inspect recovery settings.  I agree that that's important, but it
doesn't look like there is a consensus that it justifies all the drawbacks.

That said, there is a much simpler way to achieve that specific
functionality: Expose all the recovery settings as fake read-only GUC
variables.  See attached patch for an example.

Btw., I'm not sure that everyone will be happy to have primary_conninfo
visible, since it might contain passwords.

> ... and there you hit on one of the other issues with recovery.conf,
> which is that it's a configuration file with configuration parameters
> which gets automatically renamed when a standby is promoted.  This plays
> merry hell with configuration management systems.  The amount of
> conditional logic I've had to write for Salt to handle recovery.conf
> truly doesn't bear thinking about.  There may be some other way to make
> recovery.conf configuration-management friendly, but I haven't thought
> of it.

I have written similar logic, and while it's not pleasant, it's doable.
 This issue would really only go away if you don't use a file to signal
recovery at all, which you have argued for, but which is really a
separate and more difficult problem.