|From:||Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>|
|Subject:||Re: Ideas for a relcache test mode about missing invalidations|
|Views:||Raw Message | Whole Thread | Download mbox|
At Wed, 1 Aug 2018 09:25:18 -0700, Andres Freund <andres(at)anarazel(dot)de> wrote in <20180801162518(dot)jnb2ql5dfmgwp4qo(at)alap3(dot)anarazel(dot)de>
> The issue at  is caused by missing invalidations, and  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.
>  http://archives.postgresql.org/message-id/CAKoxK%2B5fVodiCtMsXKV_1YAKXbzwSfp7DgDqUmcUAzeAhf%3DHEQ%40mail.gmail.com
>  https://email@example.com
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..
NTT Open Source Software Center
|Next Message||Amit Kapila||2018-08-03 08:39:23||Re: Explain buffers wrong counter with parallel plans|
|Previous Message||Amit Langote||2018-08-03 08:28:38||Re: partition tree inspection functions|