Re: Support for N synchronous standby servers - take 2

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Support for N synchronous standby servers - take 2
Дата
Msg-id CAA4eK1LBA-xvns-c8YbaOueG95d+VJ1PFy-He3n-OOCF5ReZDw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Support for N synchronous standby servers - take 2  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Ответы Re: Support for N synchronous standby servers - take 2  (Michael Paquier <michael.paquier@gmail.com>)
Список pgsql-hackers
On Wed, Apr 20, 2016 at 12:46 PM, Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> wrote:
>
>
> assign_s_s_names causes SEGV when it is called without calling
> check_s_s_names. I think that's not the case for this varialbe
> because it is unresettable amid a session. It is very uneasy for
> me but I don't see a proper means to reset
> syncrep_parse_result.
>

Is it because syncrep_parse_result is not freed after creating a copy of it in assign_synchronous_standby_names()?  If it so, then I think we need to call SyncRepFreeConfig(syncrep_parse_result); in assign_synchronous_standby_names at below place:

+ /* Copy the parsed config into TopMemoryContext if exists */

+ if (syncrep_parse_result)

+ SyncRepConfig = SyncRepCopyConfig(syncrep_parse_result);

Could you please explain how to trigger the scenario where you have seen SEGV?



With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

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

Предыдущее
От: Gavin Flower
Дата:
Сообщение: Re: max_parallel_degree > 0 for 9.6 beta
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Support for N synchronous standby servers - take 2