Re: Avoid orphaned objects dependencies, take 3

Hi,

On Mon, Aug 19, 2024 at 03:35:14PM +0000, Bertrand Drouvot wrote:
> 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.

rebased (v17 attached).

Regards,

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