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

From Robert Haas
Subject Re: Avoid orphaned objects dependencies, take 3
Date
Msg-id CA+TgmoYYMPV1eowJmRVW6rczHnmuyfh_UR7Ge8dbtpaD6sVewA@mail.gmail.com
Whole thread Raw
In response to Re: Avoid orphaned objects dependencies, take 3  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-hackers
On Wed, May 21, 2025 at 1:18 PM Jeff Davis <pgsql@j-davis.com> wrote:
> Of course relation_open() takes a lock, but sometimes relation_open()
> is hidden in the call stack below other functions where it's not so
> obvious.

Probably true, although some of those are probably code that could
stand to be improved.

> > Yeah, that's not a terrible idea. I still like the idea I thought
> > Bertrand was pursuing, namely, to take no lock in
> > recordDependencyOn()
> > but assert that the caller has previously acquired one. However, we
> > could still do the Assert() check with this design when NoLock is
> > passed, so I think this is a reasonable alternative to that design.
>
> I'd have to see the patch to see whether I liked the end result. But
> I'm guessing that involves a lot of non-mechanical changes in the call
> sites, and also relies on test coverage for all of them.

Sure, fair enough.

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: vignesh C
Date:
Subject: Re: Logical Replication of sequences
Next
From: Robert Haas
Date:
Subject: Re: PATCH: jsonpath string methods: lower, upper, initcap, l/r/btrim, replace, split_part