On Sun, Feb 10, 2019 at 8:13 AM Tom Lane <t...@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
