Horton

Re: Recovering from detoast-related catcache invalidations

Xiaoran Wang <fanfuxiaoran@gmail.com>

View thread
From: Xiaoran Wang <fanfuxiaoran@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@lists.postgresql.org, Andres Freund <andres@anarazel.de>
Date: 2024-01-13T05:16:52Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix catcache invalidation of a list entry that's being built

  2. Cope with inplace update making catcache stale during TOAST fetch.

  3. Add previous commit to .git-blame-ignore-revs.

  4. Re-pgindent catcache.c after previous commit.

  5. Cope with catcache entries becoming stale during detoasting.

Great! That's what exactly we need.

The patch LGTM,  +1


Tom Lane <tgl@sss.pgh.pa.us> 于2024年1月13日周六 04:47写道：

> 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.
>
>                         regards, tom lane
>
>