Re: pgsql: Integrate recovery.conf into postgresql.conf

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: Sergei Kornilov <sk(at)zsrv(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz>, Postgres hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pgsql: Integrate recovery.conf into postgresql.conf
Date: 2018-11-27 14:39:23
Message-ID: 20181127143923.GS3415@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Greetings,

* Peter Eisentraut (peter(dot)eisentraut(at)2ndquadrant(dot)com) wrote:
> On 27/11/2018 13:29, Peter Eisentraut wrote:
> > On 27/11/2018 10:10, Sergei Kornilov wrote:
> >>>>  - recovery_target = immediate was replaced with recovery_target_immediate bool GUC
> >>>
> >>> Why?
> >> Due this comment: https://www.postgresql.org/message-id/20181126172118.GY3415%40tamriel.snowman.net
> >>> I've not been following this very closely, but seems like
> >>> recovery_target_string is a bad idea.. Why not just make that
> >>> 'recovery_target_immediate' and make it a boolean? Having a GUC that's
> >>> only got one valid value seems really odd.
> >
> > It is a bit odd, but that's the way it's been, and I don't see a reason
> > to change it as part of this fix. We are attempting to fix the way the
> > GUC parameters are parsed, not change the name and meaning of the
> > parameters themselves.

I disagree quite a bit- we're whacking around how recovery works and
this has been a wart since it went in because the contemplated later
changes to have more than one value be accepted there never
materialized, so we might as well change it while we're changing
everything else and clean it up.

If we really want to change it later we can do that, but we've evidently
decided to go the opposite direction and have multiple GUCs instead, so
let's be consistent.

> The attached seems to be the simplest way to fix this. (Needs
> documentation updates, test updates, error message refinement.)

Sure, this approach seems fine to me and is perhaps a bit cleaner.

Thanks!

Stephen

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Michael Banck 2018-11-27 15:26:45 Re: pgsql: Add TAP tests for pg_verify_checksums
Previous Message Peter Eisentraut 2018-11-27 14:21:39 pgsql: Update ssl test certificates and keys

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2018-11-27 14:45:04 Re: Remove Deprecated Exclusive Backup Mode
Previous Message Tom Lane 2018-11-27 14:37:17 Re: SSL tests failing with "ee key too small" error on Debian SID