Re: unite recovery.conf and postgresql.conf

On Fri, Sep 23, 2011 at 12:51 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> I'm happy to make upgrades easier, but I want a path which eventually
> ends in recovery.conf going away.  It's a bad API, confuses our users,
> and is difficult to support and maintain.

I agree.

GUC = Grand Unified Configuration, but recovery.conf is an example of
where it's not so unified after all. We've already done a non-trivial
amount of work to allow recovery.conf values to be specified without
quotes, a random incompatibility with GUCs that resulted from having
different parsing code for each file. If that were the last issue,
then maybe it wouldn't be worth worrying about, but it's not. For
example, it would be nice to have reload behavior on SIGHUP. And we
keep talking about having an ALTER SYSTEM SET guc = value or SET
PERMANENT guc = value command, and I think ALTER SYSTEM SET
recovery_target_time = '...' would be pretty sweet. I don't want us
to have to implement such things separately for postgresql.conf and
recovery.conf.

Now, it's true that Simon's proposal (of having recovery.conf
automatically included) if it exists doesn't necessarily preclude
those things. But it seems to me that it is adding a lot of
complexity to core for a pretty minimal benefit to end-users, and that
the semantics are not going to end up being very clean. For example,
now you potentially have the situation where recovery.conf has
work_mem=128MB and postgresql.conf has work_mem=4MB, and now when you
end recovery you've got to make sure that everyone picks up the new
setting. Now, in some sense you could say that's a feature addition,
and I'm not going to deny that it might be useful to some people, but
I think it's also going to require a fairly substantial convolution of
the GUC machinery, and it's going to discourage people from moving
away from recovery.conf. And like Josh, I think that ought to be the
long-term goal, for the reasons he states.

I don't want to go willy-nilly breaking third-party tools that work
with PostgreSQL, but in this case I think that the reason there are so
many tools in the first place is because what we're providing in core
is not very good. If we are unwilling to improve it for fear of
breaking compatibility with the tools, then we are stuck.

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