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.
Isolation tests should be added to demonstrate the issues it is solving.
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 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 not familiar enough with them so maybe there
is some fundamental misunderstanding on my end.
--
Ronan Dunklau