Re: Recovering from detoast-related catcache invalidations

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Recovering from detoast-related catcache invalidations
Дата
Msg-id 329632.1705011663@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Recovering from detoast-related catcache invalidations  (Xiaoran Wang <fanfuxiaoran@gmail.com>)
Ответы Re: Recovering from detoast-related catcache invalidations  (Xiaoran Wang <fanfuxiaoran@gmail.com>)
Список pgsql-hackers
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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Euler Taveira"
Дата:
Сообщение: Re: speed up a logical replica setup
Следующее
От: "Euler Taveira"
Дата:
Сообщение: Re: speed up a logical replica setup