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@sss.pgh.pa.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