Re: Leader backend hang on IPC/ParallelFinish when LWLock held at parallel query start

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Leader backend hang on IPC/ParallelFinish when LWLock held at parallel query start
Дата
Msg-id 3459938.1731007759@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Leader backend hang on IPC/ParallelFinish when LWLock held at parallel query start  (Noah Misch <noah@leadboat.com>)
Ответы Re: Leader backend hang on IPC/ParallelFinish when LWLock held at parallel query start
Список pgsql-bugs
Noah Misch <noah@leadboat.com> writes:
> On Thu, Nov 07, 2024 at 12:17:21PM -0500, Tom Lane wrote:
>> While working on the release notes, I noticed that nothing further
>> got done about this concern.  What do you think of adding a test
>> somewhere early in executor startup, to the effect of
>>
>>     if (!INTERRUPTS_CAN_BE_PROCESSED())
>>         ereport(ERROR,
>>                 (errmsg("cannot start a query with interrupts disabled")));
>>
>> It's definitely a band-aid, but it seems better than leaving
>> things at the status quo.

> That would fire in queries that don't error or hang today, so I think that
> would be worse than the status quo.

Good point.

> This thread's previous commit just forced a serial plan.

My concern is that the previous commit forced new plans to be serial,
but did nothing about re-use of an existing plan.

> The executor
> counterpart would look like having the executor do what it does when there are
> no free worker slots.

Ah, that could be a way out.  Stick an INTERRUPTS_CAN_BE_PROCESSED()
call somewhere in there?  That could even allow us to revert the
planner change, which would simplify testing of the executor change.

            regards, tom lane



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