On Wed, 2025-05-21 at 12:55 -0400, Robert Haas wrote:
> > ...like generate_partition_qual() taking a lock on the parent or
> > CheckAttributeType() taking a lock on the typrelid...
>
> To me, relation_open() feels like the kind of operation that I would
> expect to take a lock. If I open something, I must have acquired some
> resource on it that I will then use for a while before closing the
> object.
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.
>
> 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.
Regards,
Jeff Davis
