Re: Turning recovery.conf into GUCs

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Josh Berkus <josh(at)agliodbs(dot)com>, Alex Shulgin <ash(at)commandprompt(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Jaime Casanova <jaime(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Turning recovery.conf into GUCs
Date: 2015-01-06 21:22:09
Message-ID: 54AC5201.5010905@gmx.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

Attachment Content-Type Size
recovery-guc.patch text/x-diff 2.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stefan Kaltenbrunner 2015-01-06 21:30:23 Re: Updating copyright notices to 2015 for PGDG
Previous Message Bruce Momjian 2015-01-06 21:16:56 Re: Updating copyright notices to 2015 for PGDG