| From: | Noah Misch <noah(at)leadboat(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| 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 17:31:12 |
| Message-ID: | 20241108173112.c7.nmisch@google.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Fri, Nov 08, 2024 at 11:46:36AM -0500, Tom Lane wrote:
> 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.
Looks perfect. Thank you.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2024-11-08 17:56:55 | Re: Leader backend hang on IPC/ParallelFinish when LWLock held at parallel query start |
| Previous Message | Ľuboslav Špilák | 2024-11-08 17:22:46 | Segmentation fault - PostgreSQL 17.0 |