Re: Avoid orphaned objects dependencies, take 3

Hi,

On Wed, Jul 10, 2024 at 07:31:06AM +0000, Bertrand Drouvot wrote:
> So, to sum up:
>
> A. Locking is now done exclusively with LockNotPinnedObject(Oid classid, Oid objid)
> so that it's now always clear what object we want to acquire a lock for. It means
> we are not manipulating directly an object address or a list of objects address
> as it was the case when the locking was done "directly" within the dependency code.
>
> B. A special case is done for objects that belong to the RelationRelationId class.
> For those, we should be in one of the two following cases that would already
> prevent the relation to be dropped:
>
> 1. The relation is already locked (could be an existing relation or a relation
> that we are creating).
>
> 2. The relation is protected indirectly (i.e an index protected by a lock on
> its table, a table protected by a lock on a function that depends the table...)
>
> To avoid any risks for the RelationRelationId class case, we acquire a lock if
> there is none. That may add unnecessary lock for 2. but that seems worth it.
>

Please find attached v16, mandatory rebase due to 80ffcb8427.

Regards,

--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com