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

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Making WAL receiver startup rely on GUC context forprimary_conninfo and primary_slot_name
Дата
Msg-id 20190110105720.GN2157@paquier.xyz
обсуждение исходный текст
Ответ на Re: Making WAL receiver startup rely on GUC context for primary_conninfo and primary_slot_name  (Sergei Kornilov <sk@zsrv.org>)
Ответы Re: Making WAL receiver startup rely on GUC context for primary_conninfo and primary_slot_name  (Sergei Kornilov <sk@zsrv.org>)
Список pgsql-hackers
On Thu, Jan 10, 2019 at 01:10:16PM +0300, Sergei Kornilov wrote:
> Without both ready_to_display and cleaning in RequestXLogStreaming
> we do not show outdated PrimaryConnInfo in case walreceiver just
> started, but does not connected yet? While waiting walrcv_connect
> for example.

Good point.  There is a gap between the moment the WAL receiver PID is
set when the WAL receiver starts up and the moment where the different
fields are reset to 0 which is not good as it could be possible that
the user sees the information from the previous WAL receiver, so we
should move the memset calls when the PID is set, reaching a state
where the PID is alive but where there is no connection yet.  The port
number needs a similar treatment.

Looking closer at the code, it seems to me that it would be a good
thing if we update the shared memory state when the WAL receiver dies,
so as not only the PID is set to 0, but all connection-related
information gets the call.

With all those comments I am finishing with the updated attached.
Thoughts?
--
Michael

Вложения

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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: [Sender Address Forgery]Re: error message when subscriptiontarget is a partitioned table
Следующее
От: Sergei Kornilov
Дата:
Сообщение: Re: Making WAL receiver startup rely on GUC context for primary_conninfo and primary_slot_name