On Sun, Jan 27, 2013 at 7:14 AM, Phil Sorber <phil(at)omniti(dot)com> wrote:
> On Wed, Jan 23, 2013 at 6:36 AM, Michael Paquier
> <michael(dot)paquier(at)gmail(dot)com> wrote:
> >
> > On 2013/01/23, at 18:12, Simon Riggs <simon(at)2ndQuadrant(dot)com> wrote:
> >
> >> On 23 January 2013 04:49, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
> wrote:
> >>
> >>> - recovery.conf is removed (no backward compatibility in this version
> of the
> >>> patch)
> >>
> >> If you want to pursue that, you know where it leads. No, rebasing a
> >> rejected patch doesn't help, its just relighting a fire that shouldn't
> >> ever have been lit.
> >>
> >> Pushing to do that out of order is just going to drain essential time
> >> out of this CF from all of us.
> > No problem to support both. The only problem I see is if the same
> parameter is defined in recovery.conf and postgresql.conf, is the priority
> given to recovery.conf?
>
> I would think that if someone created a recovery.conf file they would
> expect that to be given priority. Otherwise they would know that was a
> deprecated method and would set it in postgresql.conf only.
>
Please find attached an half-cooked patch supporting both postgresql.conf
and recovery.conf. Priority is given to recovery.conf if the same parameter
is specified in both files. I have updated the docs in consequence but I
think they can be improved.
The main modification here is in xlog.c:readRecoveryCommandFile where the
deparsed output values of recovery.conf is transferred to the new GUCs
using SetConfigOption($OPTION, $VALUE, PGC_POSTMASTER, PGC_S_OVERRIDE) as
bridge. This does not work yet, SetConfigOption is not able to detect the
new values. Comments?
--
Michael Paquier
http://michael.otacoo.com