|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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.
|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|