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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: Francesco Degrassi <francesco(dot)degrassi(at)optionfactory(dot)net>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: Leader backend hang on IPC/ParallelFinish when LWLock held at parallel query start
Date: 2024-11-07 19:29:19
Message-ID: 3459938.1731007759@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Noah Misch <noah(at)leadboat(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Mineharu Takahara 2024-11-07 19:35:53 Suboptimal query plans for BETWEEN SYMMETRIC operations
Previous Message Noah Misch 2024-11-07 19:22:33 Re: Leader backend hang on IPC/ParallelFinish when LWLock held at parallel query start