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: <20240918053026.79.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> <1744648.1726636728@sss.pgh.pa.us>
 <20240918053026.79.nmisch@google.com>
Comments: In-reply-to Noah Misch <noah@leadboat.com>
	message dated "Tue, 17 Sep 2024 22:30:26 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1748002.1726638331.1@sss.pgh.pa.us>
Date: Wed, 18 Sep 2024 01:45:31 -0400
Message-ID: <1748003.1726638331@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1748003.1726638331%40sss.pgh.pa.us>
Precedence: bulk

Noah Misch <noah@leadboat.com> writes:
> What if we just ignored the plancache when uninterruptible?  The new planner
> check would then suffice.

Only if you believe that parallel-query is the only problem,
which is something I seriously doubt.  I fear that the
committed patch is just a band-aid over one symptom of the
general problem that we can't permit arbitrary operations
to be invoked from a btree comparison function.  It's late
here so I'm not sufficiently awake to think of examples,
but I'm sure there are some.

However ... clearly a maliciously-coded btree support function can
do arbitrarily bad stuff.  We restrict creation of opclasses to
superusers for exactly that reason.  If our ambitions are only
to prevent support functions from *accidentally* causing problems,
is disabling parallel query enough?  I'm still pretty uncomfortable
about it, but it's less obviously insufficient than in the general
case.

			regards, tom lane