Re: SegFault on 9.6.14

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: SegFault on 9.6.14
Дата
Msg-id 21011.1563457506@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: SegFault on 9.6.14  (Thomas Munro <thomas.munro@gmail.com>)
Ответы Re: SegFault on 9.6.14  (Amit Kapila <amit.kapila16@gmail.com>)
Re: SegFault on 9.6.14  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
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.  See the
commentary about EXEC_FLAG_REWIND in executor.h:

 * REWIND indicates that the plan node should try to efficiently support
 * rescans without parameter changes.  (Nodes must support ExecReScan calls
 * in any case, but if this flag was not given, they are at liberty to do it
 * through complete recalculation.  Note that a parameter change forces a
 * full recalculation in any case.)

If nodeLimit is doing something that's incompatible with that, it's
nodeLimit's fault; and similarly for the parallel machinery.

If you want to do otherwise, you are going to be inventing a whole
bunch of complicated and doubtless-initially-buggy control logic
to pass down information about whether a rescan might be possible.
That doesn't sound like a recipe for a back-patchable fix.  Perhaps
we could consider redesigning the rules around REWIND in a future
version, but that's not where to focus the bug fix effort.

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Ryan Lambert
Дата:
Сообщение: Re: Built-in connection pooler
Следующее
От: Thom Brown
Дата:
Сообщение: Re: SQL/JSON path issues/questions