Horton

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

Francesco Degrassi <francesco.degrassi@optionfactory.net>

View thread View on postgr.es
From: Francesco Degrassi <francesco.degrassi@optionfactory.net>
To: Noah Misch <noah@leadboat.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Peter Geoghegan <pg@bowt.ie>, pgsql-bugs@lists.postgresql.org
Date: 2024-09-19T06:52:09Z
Lists: 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

Commits

  1. Improve fix for not entering parallel mode when holding interrupts.

  2. Don't enter parallel mode when holding interrupts.

  3. Add has_largeobject_privilege function.