Re: unite recovery.conf and postgresql.conf

On Tue, Nov 1, 2011 at 9:11 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> On 11/1/11 12:29 PM, Robert Treat wrote:
>> "Starting in 9.2, you should use pg_ctl standby to launch your
>> database for normal operations and/or in cases where you are writing
>> init scripts to control your production databases. For backwards
>> compatibility, if you require the old behavior of using a
>> recovery.conf, we would recommend you use pg_ctl start instead".
>
> Gah.
>
> There is no way we're getting distro packagers to switch from pg_ctl
> start.  Also, a lot of distros use the "postgres" command rather than
> pg_ctl anything.
>
> Messing with pg_ctl is not really a solution for this, since few people
> in production environments call it directly.  Nobody I know, anyway.
>
> So Simon's suggested compromise still puts backwards compatibility ahead
> of promoting the new API.  This would result in nobody supporting the
> new API until the day we remove the old one from the code.

Which will never happen, since part of the proposal is that PITR will
only be supported using the old method.

> I think adding "recovery_conf_location = ''" to postgresql.conf is a
> much better compromise.  Assuming we can stand the code complexity ...

I think that might have some possibilities. But how does that work in
detail? If you set it to empty, then the recovery_* parameters are
just GUCs, I suppose: which seems fine. But if you set it to a
non-empty value then what happens, exactly? The recovery.conf
settings clobber anything in postgresql.conf, and when we exit
recovery we reload the config, discarding any settings we got from
recovery.conf? That might not be too bad.

I think we need to back up and figure out what problem we're trying to
solve here. IMV, the answer is "setting up a standby is too
complicated and requiring yet another configuration file to do it
makes it even more complicated". If the mechanism we introduce to
"solve" that problem is more complicated than what we have now, it
might end up being a net regression in terms of usability.

I feel like changing everything that's currently in recovery.conf to
GUCs and implementing SET PERSISTENT would give everyone what they
need, admittedly without perfect backward compatibility, but perhaps
close enough for government work, and a step forward overall.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company