From: | "Drouvot, Bertrand" <bdrouvot(at)amazon(dot)com> |
---|---|
To: | Ronan Dunklau <ronan(dot)dunklau(at)aiven(dot)io>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Cc: | 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-09-20 10:50:30 |
Message-ID: | 8a4025cb-739e-7e1a-785b-b67218607768@amazon.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
Thanks
Bertrand
From | Date | Subject | |
---|---|---|---|
Next Message | vignesh C | 2021-09-20 10:50:39 | Re: Added schema level support for publication. |
Previous Message | Fabrice Chapuis | 2021-09-20 10:40:30 | Re: Logical replication timeout problem |