At Wed, 1 Aug 2018 09:25:18 -0700, Andres Freund <and...@anarazel.de> wrote in <20180801162518.jnb2ql5dfmgwp...@alap3.anarazel.de> > Hi, > > The issue at [1] is caused by missing invalidations, and [2] seems like > a likely candidate too. I wonder if it'd be good to have a relcache test > mode akin to CLOBBER_CACHE_ALWAYS and RELCACHE_FORCE_RELEASE, that tries > to ensure that we've done sufficiently to ensure the right invalidations > are sent. > > I think what we'd kind of want is to ensure that relcache entries are > rebuilt at the earliest possible time, but *not* later. That'd mean > they're out of date if there's missing invalidations. Unfortunately I'm > not clear on how that'd be achievable? Ideas? > > The best I can come up with is to code some additional dependencies into > CacheInvalidateHeapTuple(), and add tracking ensuring we've sent the > right messages. But that seems somewhat painful and filled with holes. > > [1] > http://archives.postgresql.org/message-id/CAKoxK%2B5fVodiCtMsXKV_1YAKXbzwSfp7DgDqUmcUAzeAhf%3DHEQ%40mail.gmail.com > [2] https://www.postgresql.org/message-id/12259.1532117...@sss.pgh.pa.us
FWIW, I revisit here. Maybe stupid, but does it make sense that we always build a new relcache entry in RelationIdGetRelation then "logically" compare it with the entry found in relcache? I'm not sure how referece count affects this, though.. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
