Re: pgsql: Don't enter parallel mode when holding interrupts.

On Wed, Sep 18, 2024 at 3:27 AM Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> wrote:
> On Wed, 2024-09-18 at 02:58 +0000, Noah Misch wrote:
> > Don't enter parallel mode when holding interrupts.
> >
> > Doing so caused the leader to hang in wait_event=ParallelFinish, which
> > required an immediate shutdown to resolve. Back-patch to v12 (all
> > supported versions).
> >
> > Francesco Degrassi
> >
> > Discussion: https://postgr.es/m/CAC-SaSzHUKT=vZJ8MPxYdC_URPfax+yoA1hKTcF4ROz_Q6z0_Q@mail.gmail.com
>
> Does that warrant mention on this page?
> https://www.postgresql.org/docs/current/when-can-parallel-query-be-used.html

IMHO, no. This seems too low-level and too odd to mention.

TBH, I'm kind of surprised to learn that it's possible to start
executing a query while holding an LWLock. I see Tom is expressing
some doubts on the original thread, too. I wonder if we should instead
be erroring out if an LWLock is held at the start of query execution
-- or even earlier, like when we try to call a plpgsql function while
holding one. Leaving parallel query aside, what would prevent us from
attempting to reacquire the exact same LWLock that we already hold and
self-deadlocking? Or attempting to acquire some other LWLock and
deadlocking that way? I don't really feel like this is a parallel
query problem. I don't think we should be trying to run any
user-defined code while holding an LWLock, unless that code is written
in C (or C++, Rust, etc.). Trying to run procedural code at that point
doesn't seem reasonable.

--
Robert Haas
EDB: http://www.enterprisedb.com