pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Jeff Davis <pgsql@j-davis.com>
To: Robert Haas <robertmhaas@gmail.com>
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: Alexander Lakhin <exclusion@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org, Tom Lane <tgl@sss.pgh.pa.us>
Subject: Re: Avoid orphaned objects dependencies, take 3
Date: Mon, 19 May 2025 10:02:52 -0700
Message-ID: <a52286f7af47df441a624e2f1aeb06fd87dfc896.camel@j-davis.com> (raw)
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>

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.
> 
> 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?

> 
> 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






view thread (93+ messages)  latest in thread

Message-ID: <a52286f7af47df441a624e2f1aeb06fd87dfc896.camel@j-davis.com>
Permalink:  ../a52286f7af47df441a624e2f1aeb06fd87dfc896.camel@j-davis.com/
Also on:    postgresql.org/message-id/a52286f7af47df441a624e2f1aeb06fd87dfc896.camel@j-davis.com

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: pgsql@j-davis.com, robertmhaas@gmail.com, bertranddrouvot.pg@gmail.com, michael@paquier.xyz, exclusion@gmail.com, tgl@sss.pgh.pa.us
  Subject: Re: Avoid orphaned objects dependencies, take 3
  In-Reply-To: <a52286f7af47df441a624e2f1aeb06fd87dfc896.camel@j-davis.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox