Re: Avoid orphaned objects dependencies, take 3

Hi,

On Mon, Oct 28, 2024 at 09:30:19AM +0000, Bertrand Drouvot wrote:
> 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).

rebased (v18 attached).

Regards,

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