Re: Support for N synchronous standby servers - take 2
От | Michael Paquier |
---|---|
Тема | Re: Support for N synchronous standby servers - take 2 |
Дата | |
Msg-id | CAB7nPqTP8CjMykaGrWUKDpYytqFDDAyUPuVtZH92GT-LHG1+fA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Support for N synchronous standby servers - take 2 (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: Support for N synchronous standby servers - take 2
|
Список | pgsql-hackers |
On Sat, Apr 23, 2016 at 7:44 PM, Amit Kapila <amit.kapila16@gmail.com> wrote: > 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? Seeing this discussion moving on, I am wondering if we should not discuss those improvements for 9.7. We are getting close to beta 1, and this is clearly not a bug, and it's not like HEAD is broken. So I think that we should not take the risk to make the code unstable at this stage. -- Michael
В списке pgsql-hackers по дате отправления: