On Sat, Apr 23, 2016 at 7:44 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: > On Wed, Apr 20, 2016 at 12:46 PM, Kyotaro HORIGUCHI > <horiguchi.kyot...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers