Message-ID: <a52286f7af47df441a624e2f1aeb06fd87dfc896.camel@j-davis.com>
Subject: Re: Avoid orphaned objects dependencies, take 3
From: Jeff Davis <pgsql@j-davis.com>
To: Robert Haas <robertmhaas@gmail.com>, Bertrand Drouvot
	 <bertranddrouvot.pg@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, Alexander Lakhin
	 <exclusion@gmail.com>, pgsql-hackers@lists.postgresql.org, Tom Lane
	 <tgl@sss.pgh.pa.us>
Date: Mon, 19 May 2025 10:02:52 -0700
In-Reply-To: 
 <CA+TgmoYAv09Y9Y8-yOMzTCijzZeVqFrLBx6Y4+VPh0CMg476Uw@mail.gmail.com>
References: <62310067-6dc4-97ab-6724-7d3602b5056d@gmail.com>
	 <ZinjZmaMEEkOSfZ0@ip-10-97-1-34.eu-west-3.compute.internal>
	 <403075e1-4d60-09e2-a06a-749cd9d88f66@gmail.com>
	 <ZioEJafHC95wjfMk@ip-10-97-1-34.eu-west-3.compute.internal>
	 <d815344e-a6a2-617a-d35f-012e5e89f29f@gmail.com>
	 <Zjy/o3t/26exwj5Z@ip-10-97-1-34.eu-west-3.compute.internal>
	 <ZkQMYVxbOxFD0519@paquier.xyz>
	 <ZkRy73Q2NDBT0Avq@ip-10-97-1-34.eu-west-3.compute.internal>
	 <ZkSO5qlRNnFimJev@ip-10-97-1-34.eu-west-3.compute.internal>
	 <CA+TgmoYQh9y3yWm9keq5EzjLBw3y_kcQJ5-rUJtCcJHs6YNicg@mail.gmail.com>
	 <Zk3HLvMhft2taFIz@ip-10-97-1-34.eu-west-3.compute.internal>
	 <CA+TgmoYAv09Y9Y8-yOMzTCijzZeVqFrLBx6Y4+VPh0CMg476Uw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.52.3-0ubuntu1 
MIME-Version: 1.0
Archived-At: 
 <https://www.postgresql.org/message-id/a52286f7af47df441a624e2f1aeb06fd87dfc896.camel%40j-davis.com>
Precedence: bulk

On Wed, 2024-05-22 at 10:48 -0400, Robert Haas wrote:
> > Then, Tom proposed another approach in [2] which is that "creation
> > DDL will have
> > to take a lock on each referenced object that'd conflict with a
> > lock taken by DROP".
> > This is the one the current patch is trying to implement.
>=20
> It's a clever idea, but I'm not sure that I like it.

I'm not sure if you intended it this way, but using "clever" here
suggests that it's an unusual trick. But isn't that the kind of thing
heavyweight locks are for?

>=20
> My concern was really more about the maintainability of
> the code. I fear that if we add code that takes heavyweight locks in
> surprising places, we might later find the behavior difficult to
> reason about.

FWIW, a lock while recording a dependency would not be surprising to
me. Assuming that heavyweight locks are the right approach, the locks
need to be taken somewhere. And expecting all the callers to get it
right seems error-prone.

This is a long thread so I must be missing some problem or complication
here.

Regards,
	Jeff Davis