On Fri, Sep 23, 2011 at 12:51 PM, Josh Berkus <j...@agliodbs.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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers