Re: Ideas for a relcache test mode about missing invalidations

From: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
To: andres(at)anarazel(dot)de
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Ideas for a relcache test mode about missing invalidations
Date: 2018-08-03 08:30:38
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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>
> 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
> 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]
> [2]

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..


Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Browse pgsql-hackers by date

  From Date Subject
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