Re: Leader backend hang on IPC/ParallelFinish when LWLock held at parallel query start - Mailing list pgsql-bugs

From Francesco Degrassi
Subject Re: Leader backend hang on IPC/ParallelFinish when LWLock held at parallel query start
Date
Msg-id CAC-SaSzTBHeOF2-K117XKS5UZU=Tibn-zZMRqPRGptgvfxWRrg@mail.gmail.com
Whole thread Raw
In response to Re: Leader backend hang on IPC/ParallelFinish when LWLock held at parallel query start  (Noah Misch <noah@leadboat.com>)
List pgsql-bugs
On Thu, 19 Sept 2024 at 04:53, Noah Misch <noah@leadboat.com> wrote:
> For what it's worth, I tried making standard_ExecutorStart() warn if
> !INTERRUPTS_CAN_BE_PROCESSED().  Only this thread's new test and
> 004_verify_nbtree_unique reached the warning.  (That's not a surprise.)

The reproducer I provided is actually a minimization of
004_verify_nbtree_unique, so it's just the one case actually.

> On Wed, Sep 18, 2024 at 08:59:22AM -0400, Peter Geoghegan wrote:
> > The test case provided was intended to be illustrative of a problem
> > that some foreign data wrapper ran into, when it used SPI.
>
> Ideally, we'd block those or at least warn under assertions so FDW authors
> don't accidentally run the executor with an LWLock held.  Unlike the opclass
> case, we so far don't have a valid use case for holding an LWLock there.  In
> other words, if the opclass use case is the only known-valid one, it would be
> nice to have checks so new use cases don't creep in.

My 2c as a FDW developer, having a warning when calling into the SPI with a
LWLock held would have allowed us to identify this issue months ago, well
before we  stumbled into a parallel plan and hang.

Best regards

--
Francesco



pgsql-bugs by date:

Previous
From: Noah Misch
Date:
Subject: Re: Leader backend hang on IPC/ParallelFinish when LWLock held at parallel query start
Next
From: PG Bug reporting form
Date:
Subject: BUG #18624: Memory Leak Issue with PostgreSQL Connection During COPY Command Execution.