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

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Making WAL receiver startup rely on GUC context forprimary_conninfo and primary_slot_name
Дата
Msg-id 20190111004147.d6g2si7dtfi2sbtu@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Making WAL receiver startup rely on GUC context forprimary_conninfo and primary_slot_name  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: Making WAL receiver startup rely on GUC context forprimary_conninfo and primary_slot_name  (Michael Paquier <michael@paquier.xyz>)
Re: Making WAL receiver startup rely on GUC context forprimary_conninfo and primary_slot_name  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Hi,

On 2019-01-11 09:34:28 +0900, Michael Paquier wrote:
> On Thu, Jan 10, 2019 at 02:20:27PM +0300, Sergei Kornilov wrote:
> > Thank you, patch looks good for me.
> 
> Thanks Sergei for the review.  I have been looking at the patch again
> this morning with a fresh set of eyes and the thing looks in a
> committable shape (the GUC values for NULL checks are a bit
> inconsistent in the last patch by the way, so I have fixed them
> locally).
> 
> I'll do an extra pass on it in the next couple of days and commit.
> Then let's move on with the reloadable portions.

I still think this whole direction of accessing the GUC in walreceiver
is a bad idea and shouldn't be pursued further.  There's definite
potential for startup process and WAL receiver having different states
of GUCs, the code doesn't get meaningfully simpler, the GUC value checks
in walreceiver make for horrible reporting up the chain.

Greetings,

Andres Freund


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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: 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