Re: pgsql: Integrate recovery.conf into postgresql.conf - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: pgsql: Integrate recovery.conf into postgresql.conf
Date
Msg-id c17e63ce-b78a-dbb5-8fd1-30b2984a53b4@2ndquadrant.com
Whole thread Raw
In response to Re: pgsql: Integrate recovery.conf into postgresql.conf  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: pgsql: Integrate recovery.conf into postgresql.conf  (Sergei Kornilov <sk@zsrv.org>)
Re: pgsql: Integrate recovery.conf into postgresql.conf  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On 27/11/2018 13:29, Peter Eisentraut wrote:
> On 27/11/2018 10:10, Sergei Kornilov wrote:
>> Hello
>>
>>>>  - 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.

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

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Use durable_unlink for .ready and .done files for WAL segmentremoval
Next
From: Etsuro Fujita
Date:
Subject: postgres_fdw: oddity in costing aggregate pushdown paths