Re: SegFault on 9.6.14

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: SegFault on 9.6.14
Дата
Msg-id CAA4eK1+B-ObbTJpPij2T_Nk7gF2nXxCHUVsm8A3vmDSHyq4_Zg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: SegFault on 9.6.14  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: SegFault on 9.6.14  (Thomas Munro <thomas.munro@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Documentation fix for adding a column with a default value
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Intermittent pg_ctl failures on Windows