Horton

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

Peter Geoghegan <pg@bowt.ie>

View thread View on postgr.es
From: Peter Geoghegan <pg@bowt.ie>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Noah Misch <noah@leadboat.com>, Francesco Degrassi <francesco.degrassi@optionfactory.net>, pgsql-bugs@lists.postgresql.org
Date: 2024-09-18T12:59:22Z
Lists: pgsql-bugs 
On Wed, Sep 18, 2024 at 1:18 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Dunno ... but the OP claimed this is a case that's seen in the
> field, so maybe somebody is doing it.  On the whole I don't see
> how a btree support function can be considered not to be a low-level
> thing, so maybe restricting what it can do is the best answer.

Making it possible to do arbitrarily complicated things from B-Tree
support functions seems out of the question. We're not going to
maintain parallel versions of the code that releases buffer locks
before calling (say) the opclass ORDER proc. Just for example, how
would such a scheme work with code like _bt_check_unique?

> I fear though that the restriction can't simply be to forbid
> parallel sub-queries.

Why not?

The test case provided was intended to be illustrative of a problem
that some foreign data wrapper ran into, when it used SPI. I don't
think that the true problem was in any way related to B-Tree indexes.

-- 
Peter Geoghegan

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.