From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Jerry Sievers <gsievers19(at)comcast(dot)net>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Subject: | Re: SegFault on 9.6.14 |
Date: | 2019-07-19 03:00:42 |
Message-ID: | CAA4eK1+B-ObbTJpPij2T_Nk7gF2nXxCHUVsm8A3vmDSHyq4_Zg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jul 18, 2019 at 7:15 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Thomas Munro <thomas(dot)munro(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2019-07-19 03:02:08 | Re: Intermittent pg_ctl failures on Windows |
Previous Message | Michael Paquier | 2019-07-19 02:46:27 | Re: Documentation fix for adding a column with a default value |