Making WAL receiver startup rely on GUC context for primary_conninfoand primary_slot_name

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Making WAL receiver startup rely on GUC context for primary_conninfoand primary_slot_name
Дата
Msg-id 20181212053042.GK17695@paquier.xyz
обсуждение исходный текст
Ответы Re: Making WAL receiver startup rely on GUC context for primary_conninfo and primary_slot_name  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
Hi all,

Since 2dedf4d, recovery.conf is dead and all recovery parameters are now
GUCs.  While looking at a patch to switch primary_conninfo and
primary_slot_name to be reloadable, Sergei Kornilov had a very good
point that the WAL receiver uses a connection string and a physical slot
name based on what the startup process wants the WAL receiver to use:
https://www.postgresql.org/message-id/20181212043208.GI17695@paquier.xyz

It seems to me that doing so is now strange as the WAL receiver knows
about the GUC context, and actually it knows the parameters it should
use, so there is no point to pass down the values when requesting the
WAL receiver to start.

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.

Thoughts?
--
Michael

Вложения

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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Add timeline to partial WAL segments
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Making WAL receiver startup rely on GUC context for primary_conninfo and primary_slot_name