Re: SegFault on 9.6.14 - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: SegFault on 9.6.14
Date
Msg-id CAA4eK1+B-ObbTJpPij2T_Nk7gF2nXxCHUVsm8A3vmDSHyq4_Zg@mail.gmail.com
Whole thread Raw
In response to Re: SegFault on 9.6.14  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: SegFault on 9.6.14  (Thomas Munro <thomas.munro@gmail.com>)
List pgsql-hackers
On Thu, Jul 18, 2019 at 7:15 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Thomas Munro <thomas.munro@gmail.com> writes:
> > Hmm, so something like a new argument "bool final" added to the
> > ExecXXXShutdown() functions, which receives false in this case to tell
> > it that there could be a rescan so keep the parallel context around.
>
> I think this is going in the wrong direction.  Nodes should *always*
> assume that a rescan is possible until ExecEndNode is called.
>

I am thinking that why not we remove the part of destroying the
parallel context (and shared memory) from ExecShutdownGather (and
ExecShutdownGatherMerge) and then do it at the time of ExecEndGather
(and ExecEndGatherMerge)?   This should fix the bug in hand and seems
to be more consistent with our overall design principles.  I have not
tried to code it to see if there are any other repercussions of the
same but seems worth investigating.  What do you think?

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



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Documentation fix for adding a column with a default value
Next
From: Michael Paquier
Date:
Subject: Re: Intermittent pg_ctl failures on Windows