Re: Recovering from detoast-related catcache invalidations
От | Noah Misch |
---|---|
Тема | Re: Recovering from detoast-related catcache invalidations |
Дата | |
Msg-id | 20240114201411.d0@rfd.leadboat.com обсуждение исходный текст |
Ответ на | Re: Recovering from detoast-related catcache invalidations (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Recovering from detoast-related catcache invalidations
|
Список | pgsql-hackers |
On Fri, Jan 12, 2024 at 03:47:13PM -0500, Tom Lane wrote: > I wrote: > > This is uncomfortably much in bed with the tuple table slot code, > > perhaps, but I don't see a way to do it more cleanly unless we want > > to add some new provisions to that API. Andres, do you have any > > thoughts about that? > > Oh! After nosing around a bit more I remembered systable_recheck_tuple, > which is meant for exactly this purpose. So v4 attached. systable_recheck_tuple() is blind to heap_inplace_update(), so it's not a general proxy for invalidation messages. The commit for $SUBJECT (ad98fb1) doesn't create any new malfunctions, but I expect the systable_recheck_tuple() part will change again before the heap_inplace_update() story is over (https://postgr.es/m/flat/CAMp+ueZQz3yDk7qg42hk6-9gxniYbp-=bG2mgqecErqR5gGGOA@mail.gmail.com).
В списке pgsql-hackers по дате отправления: