Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages)

On Sun, Feb 10, 2019 at 8:13 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> How about this comment text?
>
> /*
> * The current target object should have been added to
> * targetObjects while processing the owning object; but it
> * probably got only the flag bits associated with the
> * dependency we're looking at. We need to add the objflags
> * that were passed to this recursion level, too, else we may
> * get a bogus failure in reportDependentObjects (if, for
> * example, we were called due to a partition dependency).
> *
> * If somehow the current object didn't get scheduled for
> * deletion, bleat. (That would imply that somebody deleted
> * this dependency record before the recursion got to it.)
> * Another idea would be to reacquire lock on the current
> * object and resume trying to delete it, but it seems not
> * worth dealing with the race conditions inherent in that.
> */

LGTM. I agree that referencing a counterfactual design that reacquires
the lock instead adds something.

> Just to be be clear, my inclination is to do nothing about this in v11.
> It's not apparent to me that any fix is possible given the v11 dependency
> data, at least not without downsides that'd likely outweigh the upsides.
> We've not seen field complaints about these problems.

I thought that you might have had a trick up your sleeve for v11,
although I had no idea how that would be possible without making sure
that partition dependencies came in pairs to begin with. :-)

I'll reply to your new revision of the patch separately.

--
Peter Geoghegan