Andres Freund <and...@anarazel.de> writes:
> Leaving that aside, I think there's one architectural aspect of my
> approach that I prefer over yours: Deduplicating eager cache rebuilds
> like my approach does seems quite advantageous.
That is attractive, for sure, but the other side of the coin is that
getting there seems to require a lot of ticklish redesign. We would
certainly not consider back-patching such a change normally, and I'm
unconvinced that we should do so in this case.
My thought is to do (and back-patch) my change, and then work on yours
as a performance improvement for HEAD only. I don't believe that yours
would make mine redundant, either --- they are good complementary changes
to make real sure we have no remaining bugs of this ilk. (In particular,
no matter how much de-duplication we do, we'll still have scenarios with
recursive cache flushes; so I'm not quite convinced that your solution
provides a 100% fix by itself.)
regards, tom lane
