| 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-08 16:46:36 |
| Message-ID: | 3694355.1731084396@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 02:29:19PM -0500, Tom Lane wrote:
>> Ah, that could be a way out. Stick an INTERRUPTS_CAN_BE_PROCESSED()
>> call somewhere in there?
> Exactly. If !INTERRUPTS_CAN_BE_PROCESSED(), proceed as though no workers can
> be launched.
>> That could even allow us to revert the
>> planner change, which would simplify testing of the executor change.
> True.
Here's a proposed patch along that line. I left the test case from
ac04aa84a alone, since it works perfectly well to test this way too.
We could argue about whether or not to revert the planner change.
But I'd prefer to do so, because as things stand it creates a
hard-to-reason-about source of plan instability.
regards, tom lane
| Attachment | Content-Type | Size |
|---|---|---|
| better-fix-for-noninterruptible-lockup.patch | text/x-diff | 2.1 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ľuboslav Špilák | 2024-11-08 17:22:46 | Segmentation fault - PostgreSQL 17.0 |
| Previous Message | Andres Freund | 2024-11-08 16:41:32 | Re: HashAgg degenerate case |