From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Xiaoran Wang <fanfuxiaoran(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Recovering from detoast-related catcache invalidations |
Date: | 2024-01-11 22:21:03 |
Message-ID: | 329632.1705011663@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Xiaoran Wang <fanfuxiaoran(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Euler Taveira | 2024-01-11 23:00:18 | Re: speed up a logical replica setup |
Previous Message | Euler Taveira | 2024-01-11 22:15:22 | Re: speed up a logical replica setup |