Re: Avoid orphaned objects dependencies, take 3
От | Bertrand Drouvot |
---|---|
Тема | Re: Avoid orphaned objects dependencies, take 3 |
Дата | |
Msg-id | ZoOWh65dEXamDYDW@ip-10-97-1-34.eu-west-3.compute.internal обсуждение исходный текст |
Ответ на | Re: Avoid orphaned objects dependencies, take 3 (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>) |
Ответы |
Re: Avoid orphaned objects dependencies, take 3
|
Список | pgsql-hackers |
Hi, On Mon, Jul 01, 2024 at 09:39:17AM +0000, Bertrand Drouvot wrote: > Hi, > > On Wed, Jun 26, 2024 at 10:24:41AM +0000, Bertrand Drouvot wrote: > > Hi, > > > > On Fri, Jun 21, 2024 at 01:22:43PM +0000, Bertrand Drouvot wrote: > > > 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). > > > > Please find attached v12 implementing this idea for the RelationRelationId class > > case. As mentioned, it may add unnecessary locking for 2. but I think that's > > worth it to ensure that we are always on the safe side of thing. This idea is > > implemented in LockNotPinnedObjectById(). > > Please find attached v13, mandatory rebase due to 0cecc908e97. In passing, make > use of CheckRelationOidLockedByMe() added in 0cecc908e97. Please find attached v14, mandatory rebase due to 65b71dec2d5. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
Вложения
В списке pgsql-hackers по дате отправления: