Re: Recovering from detoast-related catcache invalidations

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>

To: Xiaoran Wang <fanfuxiaoran@gmail.com>

Cc: pgsql-hackers@lists.postgresql.org, Andres Freund <andres@anarazel.de>

Date: 2024-01-13T17:18:32Z

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 →

Fix catcache invalidation of a list entry that's being built
- f217c410553d 13.19 landed
- 91fc447c21d3 16.7 landed
- 96e61b2792a5 17.3 landed
- fce17c3a53d6 14.16 landed
- ce7c406f0f8d 15.11 landed
- af8cd1639ab2 18.0 landed
Cope with inplace update making catcache stale during TOAST fetch.
- 7a21306aee0a 13.16 landed
- 11f3815d6af8 12.20 landed
- af73e37fa181 14.13 landed
- b08a4b6163eb 15.8 landed
- e4afd7153bd8 16.4 landed
- f9f47f0d93d1 17.0 landed
Add previous commit to .git-blame-ignore-revs.
- 36578fa04942 17.0 landed
Re-pgindent catcache.c after previous commit.
- d41358f4bbc8 15.6 landed
- d29a4fbacfb7 12.18 landed
- 96c019ffa3f8 17.0 landed
- 7ceeb57baddd 14.11 landed
- 56dcd71decb7 16.2 landed
- 475b3ea3c06b 13.14 landed
Cope with catcache entries becoming stale during detoasting.
- db122d426a2d 14.11 landed
- ad98fb14226a 17.0 landed
- 98e03f957436 13.14 landed
- 7e2561e1a258 16.2 landed
- 3b4d85cf159c 12.18 landed
- 2a46a0df4793 15.6 landed

Xiaoran Wang <fanfuxiaoran@gmail.com> writes:
> Hmm, how about first checking if any invalidated shared messages have been
> accepted, then rechecking the tuple's visibility?
> If there is no invalidated shared message accepted during
> 'toast_flatten_tuple',
> there is no need to do then visibility check, then it can save several
> CPU cycles.

Meh, I'd just as soon not add the additional dependency/risk of bugs.
This is an expensive and seldom-taken code path, so I don't think
shaving a few cycles is really important.

			regards, tom lane