From: Tom Lane <tgl@sss.pgh.pa.us>
To: Noah Misch <noah@leadboat.com>
cc: Francesco Degrassi <francesco.degrassi@optionfactory.net>,
        pgsql-bugs@lists.postgresql.org
Subject: Re: Leader backend hang on IPC/ParallelFinish when LWLock held at
 parallel query start
In-reply-to: <20240918030159.2a.nmisch@google.com>
References: 
 <CAC-SaSzHUKT=vZJ8MPxYdC_URPfax+yoA1hKTcF4ROz_Q6z0_Q@mail.gmail.com>
 <20240918030159.2a.nmisch@google.com>
Comments: In-reply-to Noah Misch <noah@leadboat.com>
	message dated "Tue, 17 Sep 2024 20:01:59 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1737569.1726633422.1@sss.pgh.pa.us>
Date: Wed, 18 Sep 2024 00:23:42 -0400
Message-ID: <1737570.1726633422@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1737570.1726633422%40sss.pgh.pa.us>
Precedence: bulk

Noah Misch <noah@leadboat.com> writes:
> On Mon, Sep 16, 2024 at 09:35:13PM +0200, Francesco Degrassi wrote:
>> The problem appears to manifest when a backend is holding an LWLock and
>> starting a query, and the planner chooses a parallel plan for the
>> latter.

> Thanks for the detailed report and for the fix.

I do not have much faith in this patch.  It assumes that the
condition "interrupts can be processed" is the same at plan time and
execution time.  For plans extracted from the plan cache, there seems
little reason to assume that must be true.  The proposed test case
cannot trigger that (today anyway) because SQL-language functions
don't deal in cached plans, but I suspect it could be broken with a
test case using a plpgsql function instead.

I actually think that the problem is somewhere upstream of here:
what in the world are we doing invoking planning and execution of
arbitrary queries in a context where interrupts are held off?
That seems certain to fail in multiple ways besides parallel
workers not working.  I think we need to fix whatever code
believes that that could be OK.  And maybe then insert
"Assert(INTERRUPTS_CAN_BE_PROCESSED())" at planner start
and executor start.

			regards, tom lane