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

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: pgsql: Integrate recovery.conf into postgresql.conf
Дата
Msg-id c17e63ce-b78a-dbb5-8fd1-30b2984a53b4@2ndquadrant.com
обсуждение исходный текст
Ответ на Re: pgsql: Integrate recovery.conf into postgresql.conf  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Ответы 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>)
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Use durable_unlink for .ready and .done files for WAL segmentremoval
Следующее
От: Etsuro Fujita
Дата:
Сообщение: postgres_fdw: oddity in costing aggregate pushdown paths