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
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 |