Re: Patch to avoid orphaned dependencies

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: "Drouvot, Bertrand" <bdrouvot(at)amazon(dot)com>
Cc: Ronan Dunklau <ronan(dot)dunklau(at)aiven(dot)io>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Gilles Darold <gilles(at)darold(dot)net>, "Nasby, Jim" <nasbyj(at)amazon(dot)com>, "Bossart, Nathan" <bossartn(at)amazon(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Subject: Re: Patch to avoid orphaned dependencies
Date: 2021-11-17 13:25:07
Message-ID: 5B35561B-433B-4300-930D-1404BAD50439@yesql.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 20 Sep 2021, at 12:50, Drouvot, Bertrand <bdrouvot(at)amazon(dot)com> wrote:
>
> Hi Ronan,
>
> On 9/17/21 10:09 AM, Ronan Dunklau wrote:
>> Hello Bertrand,
>>
>> Le mardi 4 mai 2021, 11:55:43 CEST Drouvot, Bertrand a écrit :
>>> Implementation overview:
>>>
>>> * A new catalog snapshot is added: DirtyCatalogSnapshot.
>>> * This catalog snapshot is a dirty one to be able to look for
>>> in-flight dependencies.
>>> * Its usage is controlled by a new UseDirtyCatalogSnapshot variable.
>>> * Any time this variable is being set to true, then the next call to
>>> GetNonHistoricCatalogSnapshot() is returning the dirty snapshot.
>>> * This snapshot is being used to check for in-flight dependencies and
>>> also to get the objects description to generate the error messages.
>>>
>> I quickly tested the patch, it behaves as advertised, and passes tests.
>
> Thanks for looking at it!
>
>>
>> Isolation tests should be added to demonstrate the issues it is solving.
>
> Good point. I'll have a look.
>
>>
>> However, I am bit wary of this behaviour of setting the DirtyCatalogSnapshot
>> global variable which is then reset after each snapshot acquisition: I'm
>> having trouble understanding all the implications of that, if it would be
>> possible to introduce an unforeseen snapshot before the one we actually want
>> to be dirty.
>
> I don't think that could be possible as long as:
>
> - this is a per backend variable
>
> - we pay attention where we set it to true
>
> But i might be missing something.
>
> Do you have any corner cases in mind?
>
>> I don't want to derail this thread, but couldn't predicate locks on the
>> pg_depend index pages corresponding to the dropped object / referenced objects
>> work as a different approach ?
>
> I'm fine to have a look at another approach if needed, but does it mean we are not happy with the current approach proposal?

This patch fails to apply as a whole, with the parts applying showing quite
large offsets. Have you had the chance to look at the isolation test asked for
above?

--
Daniel Gustafsson https://vmware.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2021-11-17 13:26:33 Re: Granting SET and ALTER SYSTE privileges for GUCs
Previous Message Xiaozhe Yao 2021-11-17 13:24:17 Propose a new hook for mutating the query bounds