Horton
Menu

Re: Avoid orphaned objects dependencies, take 3

Bertrand Drouvot <bertranddrouvot.pg@gmail.com>

View thread
From: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, Alexander Lakhin <exclusion@gmail.com>, pgsql-hackers@lists.postgresql.org, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2024-08-19T15:35:14Z
Lists: pgsql-hackers

Attachments

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

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Avoid orphaned objects dependencies

  2. Don't try to record dependency on a dropped column's datatype