Re: Avoid orphaned objects dependencies, take 3 - Mailing list pgsql-hackers

From Bertrand Drouvot
Subject Re: Avoid orphaned objects dependencies, take 3
Date
Msg-id ZnV+o92zl6tv3r96@ip-10-97-1-34.eu-west-3.compute.internal
Whole thread Raw
In response to Re: Avoid orphaned objects dependencies, take 3  (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>)
Responses Re: Avoid orphaned objects dependencies, take 3
List pgsql-hackers
Hi,

On Wed, Jun 19, 2024 at 02:11:50PM +0000, Bertrand Drouvot wrote:
> To sum up, I did not see any cases that did not lead to 1. or 2., so I think
> it's safe to not add an extra lock for the RelationRelationId case. If, for any
> reason, there is still cases that are outside 1. or 2. then they may lead to
> orphaned dependencies linked to the RelationRelationId class. I think that's
> fine to take that "risk" given that a. that would not be worst than currently
> and b. I did not see any of those in our fleet currently (while I have seen a non
> negligible amount outside of the RelationRelationId case).

Another thought for the RelationRelationId class case: we could check if there
is a lock first and if there is no lock then acquire one. That way that would
ensure the relation is always locked (so no "risk" anymore), but OTOH it may
add "unecessary" locking (see 2. mentioned previously).

I think I do prefer this approach to be on the safe side of thing, what do
you think?

Regards,

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



pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: Improve EXPLAIN output for multicolumn B-Tree Index
Next
From: Daniel Gustafsson
Date:
Subject: Re: improve ssl error code, 2147483650