Re: Continue work on changes to recovery.conf API

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Continue work on changes to recovery.conf API
Дата
Msg-id 20181125203927.f66lvh55ef5aw65g@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Continue work on changes to recovery.conf API  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: Continue work on changes to recovery.conf API  (Stephen Frost <sfrost@snowman.net>)
Re: Continue work on changes to recovery.conf API  (Sergei Kornilov <sk@zsrv.org>)
Re: Continue work on changes to recovery.conf API  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Список pgsql-hackers
Hi,

On 2018-11-25 13:24:15 -0500, Stephen Frost wrote:
> - User performs a backup with pg_basebackup -R
> - Replica is then promoted to be a primary
> - User performs a backup with pg_basebackup -R on the new primary
> - Duplicate entries end up in postgresql.auto.conf.  Ew.

Why don't we put recovery entries into postgresql.recovery.conf or such?
And overwrite rather than append?


> In the end, I'm not entirely convinced that eliminating recovery.conf is
> actually an improvement; I think I would have rather seen the original
> approach of having an 'auto' recovery.conf, but perhaps we can improve
> on this since others seemed anxious to get rid of recovery.conf (though
> I'm not sure why- seems like we'll likely end up with more code to
> handle things cleanly with a merged recovery.auto/postgresql.auto than
> if we had kept them independent).

If we ever want to have more dynamic reconfiguration around recovery
(say changing the primary and other settings at runtime, and a lot of
more advanced features), we're going to need infrastructure to deal with
that. Without the merge we'd have to duplicate the guc logic.

Greetings,

Andres Freund


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

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: [HACKERS] [PATCH] Generic type subscripting
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Continue work on changes to recovery.conf API