Date: Thu, 7 Nov 2024 11:38:23 -0800
From: Noah Misch <noah@leadboat.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
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
Message-ID: <20241107193823.dc.nmisch@google.com>
References: 
 <CAC-SaSzHUKT=vZJ8MPxYdC_URPfax+yoA1hKTcF4ROz_Q6z0_Q@mail.gmail.com>
 <20240918030159.2a.nmisch@google.com>
 <1737570.1726633422@sss.pgh.pa.us>
 <20240918050434.13.nmisch@google.com>
 <3441950.1730999841@sss.pgh.pa.us>
 <20241107192233.94.nmisch@google.com>
 <3459938.1731007759@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3459938.1731007759@sss.pgh.pa.us>
User-Agent: Mutt/2.2.12 (2023-09-09)
Archived-At: 
 <https://www.postgresql.org/message-id/20241107193823.dc.nmisch%40google.com>
Precedence: bulk

On Thu, Nov 07, 2024 at 02:29:19PM -0500, Tom Lane wrote:
> Noah Misch <noah@leadboat.com> writes:
> > This thread's previous commit just forced a serial plan.
> 
> My concern is that the previous commit forced new plans to be serial,
> but did nothing about re-use of an existing plan.

I agree.  It solved one way of reaching the problem, leaving at least one
unsolved.

> > The executor
> > counterpart would look like having the executor do what it does when there are
> > no free worker slots.
> 
> Ah, that could be a way out.  Stick an INTERRUPTS_CAN_BE_PROCESSED()
> call somewhere in there?

Exactly.  If !INTERRUPTS_CAN_BE_PROCESSED(), proceed as though no workers can
be launched.

> That could even allow us to revert the
> planner change, which would simplify testing of the executor change.

True.