> In my view, the biggest problem with recovery.conf is that the
> parameters in there are not GUCs, which means that all of the
> infrastructure that we've built for managing GUCs does not work with
> them. As an example, when we converted recovery.conf to use the same
> lexer that the GUC machinery uses, it allowed recovery.conf values to
> be specified unquoted in the same circumstances where that was already
> possible for postgresql.conf. But, you still can't use SHOW or
> pg_settings with recovery.conf parameters, and I think pg_ctl reload
> doesn't work either. If we make these parameters into GUCs, then
> they'll work the same way everything else works. Even if (as seems
> likely) we end up still needing a trigger file (or a special pg_ctl
> mode) to initiate recovery, I think that's probably a win.
I agree that it would be an improvement, and I would be happy just to
see the parameters become GUCs.
I'm just saying that I'll still be pushing to get rid of the requirement
for recovery.conf in 9.4, that's all.
PostgreSQL Experts Inc.
In response to
pgsql-hackers by date
|Next:||From: Andrew Dunstan||Date: 2013-01-03 18:36:15|
|Subject: Re: pg_upgrade test script creates port conflicts in parallel
|Previous:||From: Heikki Linnakangas||Date: 2013-01-03 18:01:41|
|Subject: pgsql: Tolerate timeline switches while "pg_basebackup -X fetch" isrun|