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
Re: Making WAL receiver startup rely on GUC context forprimary_conninfo and primary_slot_name |
Список | 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 по дате отправления: