From: Tom Lane <tgl@sss.pgh.pa.us>
To: Xiaoran Wang <fanfuxiaoran@gmail.com>
cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Recovering from detoast-related catcache invalidations
In-reply-to: 
 <CAGjhLkOoBEC9mLsnB42d3CO1vcMx71MLSEuigeABbQ8oRdA6gw@mail.gmail.com>
References: 
 <CAGjhLkOoBEC9mLsnB42d3CO1vcMx71MLSEuigeABbQ8oRdA6gw@mail.gmail.com>
Comments: In-reply-to Xiaoran Wang <fanfuxiaoran@gmail.com>
	message dated "Fri, 12 Jan 2024 01:52:21 +0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <329631.1705011663.1@sss.pgh.pa.us>
Date: Thu, 11 Jan 2024 17:21:03 -0500
Message-ID: <329632.1705011663@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/329632.1705011663%40sss.pgh.pa.us>
Precedence: bulk

Xiaoran Wang <fanfuxiaoran@gmail.com> writes:
>>> The detection of "get an invalidation" could be refined: what I did
>>> here is to check for any advance of SharedInvalidMessageCounter,
>>> which clearly will have a significant number of false positives.

> I have reviewed your patch, and it looks good.  But instead of checking for
> any advance of SharedInvalidMessageCounter ( if the invalidate message is
> not related to the current tuple, it is a little expensive)  I have another
> idea:  we can recheck the visibility of the tuple with CatalogSnapshot(the
> CatalogSnapthot must be refreshed if there is any SharedInvalidMessages) if
> it is not visible, we re-fetch the tuple, otherwise, we can continue to use
> it as it is not outdated.

Maybe, but that undocumented hack in SetHintBits seems completely
unacceptable.  Isn't there a cleaner way to make this check?

Also, I'm pretty dubious that GetNonHistoricCatalogSnapshot rather
than GetCatalogSnapshot is the right thing, because the catcaches
use the latter.

			regards, tom lane