Re: Making WAL receiver startup rely on GUC context forprimary_conninfo and primary_slot_name

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Making WAL receiver startup rely on GUC context forprimary_conninfo and primary_slot_name
Дата
Msg-id CANP8+jK=k9sj_WFedFaGRozbSuE2huMLcJME_36v+WPsBz3N3g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Making WAL receiver startup rely on GUC context for primary_conninfo and primary_slot_name  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On Wed, 12 Dec 2018 at 05:35, Andres Freund <andres@anarazel.de> wrote:
 
>What do you think about the attached to simplify the logic?  Even if
>primary_conninfo and primary_slot_name are not switched to SIGHUP this
>cleanup looks like a good thing to me.

I am not convinced this is a good idea. This allows the state of walrcv and startup to diverge, they could e.g. have different configuration, due to differently time config reloads.
 
That sounds bad, but most parameters apply to one or the other, not both.

If there are some that apply to both, then yes, coordination would be important.

It does seem likely that the new scheme will require us to look carefully at when parameters are reloaded, since the timing of reloads was never taken into account in the previous coding.
 
--
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

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

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: proposal: plpgsql pragma statement
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Undo logs