On 2020-Jan-14, Alvaro Herrera wrote:
> On 2020-Jan-13, Tom Lane wrote:
>
> > That seems fundamentally wrong. By the time we've queued an object for
> > deletion in dependency.c, we have a lock on it, and we've verified that
> > the object is still there (cf. systable_recheck_tuple calls).
> > If shdepDropOwned is doing it differently, I'd say shdepDropOwned is
> > doing it wrong.
>
> Hmm, it seems to be doing it differently. Maybe it should be acquiring
> locks on all objects in that nested loop and verified them for
> existence, so that when it calls performMultipleDeletions the objects
> are already locked, as you say.
Yeah, this solves the reported bug.
This is not a 100% solution: there's the cases when the user is removed
from an ACL and from a policy, and those deletions are done directly
instead of accumulating to the end for a mass deletion.
I had to export AcquireDeletionLock (previously a static in
dependency.c). I wonder if I should export ReleaseDeletionLock too, for
symmetry.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
