MIME-Version: 1.0
References: <20221221101846.7zsi7lscnm5ediik@alvherre.pgsql>
 <1350682.1671635927@sss.pgh.pa.us> <4191508.1674157166@sss.pgh.pa.us> <CAApHDvq0rDbt6o7mvgU8gf1VJ3hvE2sOGdhVDRTKxq5parmA6w@mail.gmail.com>
In-Reply-To: <CAApHDvq0rDbt6o7mvgU8gf1VJ3hvE2sOGdhVDRTKxq5parmA6w@mail.gmail.com>
From: Amit Langote <amitlangote09@gmail.com>
Date: Mon, 20 May 2024 21:13:21 +0900
Message-ID: <CA+HiwqEqLozRitnPZMs6kWWkvb6DgtSPKH9TbZhvtbCXJJa7Mg@mail.gmail.com>
Subject: Re: generic plans and "initial" pruning
To: David Rowley <dgrowleyml@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Alvaro Herrera <alvherre@alvh.no-ip.org>, 
	Robert Haas <robertmhaas@gmail.com>, Jacob Champion <jchampion@timescale.com>, 
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CA%2BHiwqEqLozRitnPZMs6kWWkvb6DgtSPKH9TbZhvtbCXJJa7Mg%40mail.gmail.com>
Precedence: bulk

On Sun, May 19, 2024 at 9:39=E2=80=AFAM David Rowley <dgrowleyml@gmail.com>=
 wrote:
> For #1, the locks taken for SELECT queries are less likely to conflict
> with other locks obtained by PostgreSQL, but at least at the moment if
> someone is getting deadlocks with a DDL type operation, they can
> change their query or DDL script so that locks are taken in the same
> order.  If we allowed executor startup to do this then if someone
> comes complaining that PG18 deadlocks when PG17 didn't we'd just have
> to tell them to live with it.  There's a comment at the bottom of
> find_inheritance_children_extended() just above the qsort() which
> explains about the deadlocking issue.

Thought to chime in on this.

A deadlock may occur with the execution-time locking proposed in the
patch if the DDL script makes assumptions about how a cached plan's
execution determines the locking order for children of multiple parent
relations. Specifically, the deadlock can happen if the script tries
to lock the child relations directly, instead of locking them through
their respective parent relations.  The patch doesn't change the order
of locking of relations mentioned in the query, because that's defined
in AcquirePlannerLocks().

--
Thanks, Amit Langote