Re: Avoid orphaned objects dependencies, take 3 - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Avoid orphaned objects dependencies, take 3
Date
Msg-id a52286f7af47df441a624e2f1aeb06fd87dfc896.camel@j-davis.com
Whole thread Raw
In response to Re: Avoid orphaned objects dependencies, take 3  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Avoid orphaned objects dependencies, take 3
List pgsql-hackers
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




pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: Statistics Import and Export
Next
From: Andrei Lepikhov
Date:
Subject: Re: Should we optimize the `ORDER BY random() LIMIT x` case?