Re: Request for vote to move forward with recovery.conf overhaul

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Phil Sorber <phil(at)omniti(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Request for vote to move forward with recovery.conf overhaul
Date: 2013-01-27 06:01:51
Message-ID: CAB7nPqR6NvZW5aKKR9wHiNN9hbC7eJ2QTPSi9v+hcY7bGeWFqQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Jan 27, 2013 at 1:41 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Sat, Jan 26, 2013 at 9:49 PM, Michael Paquier
> <michael(dot)paquier(at)gmail(dot)com> wrote:
> > 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?
>
> So... what happens when recovery ends? Do the settings loaded from
> recovery.conf get reverted, or what?
>
With current patch the settings are kept if set in postgresql.conf and
discarded if they are loaded as GUC after a server restart or reload.
--
Michael Paquier
http://michael.otacoo.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kohei KaiGai 2013-01-27 06:55:00 Re: [v9.3] OAT_POST_ALTER object access hooks
Previous Message Amit kapila 2013-01-27 05:58:04 Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]