From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Alexander Lakhin <exclusion(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: Avoid orphaned objects dependencies, take 3 |
Date: | 2025-05-21 17:47:17 |
Message-ID: | CA+TgmoYYMPV1eowJmRVW6rczHnmuyfh_UR7Ge8dbtpaD6sVewA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, May 21, 2025 at 1:18 PM Jeff Davis <pgsql(at)j-davis(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Shaik Mohammad Mujeeb | 2025-05-21 17:51:36 | [Util] Warn and Remove Invalid GUCs |
Previous Message | vignesh C | 2025-05-21 17:36:54 | Re: Logical Replication of sequences |