Re: type cache cleanup improvements

Alexander Korotkov <aekorotkov@gmail.com>

From: Alexander Korotkov <aekorotkov@gmail.com>

To: Alexander Lakhin <exclusion@gmail.com>

Cc: Pavel Borisov <pashkin.elfe@gmail.com>, Andrei Lepikhov <a.lepikhov@postgrespro.ru>, Teodor Sigaev <teodor@sigaev.ru>, Pgsql Hackers <pgsql-hackers@postgresql.org>, Aleksander Alekseev <aleksander@timescale.com>, Tom Lane <tgl@sss.pgh.pa.us>, Michael Paquier <michael@paquier.xyz>

Date: 2024-08-25T19:21:19Z

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 →

Maintain RelIdToTypeIdCacheHash in TypeCacheOpcCallback()
- bb78e4267817 18.0 landed
Fix concurrrently in typcache_rel_type_cache.sql
- aa1e898dea66 18.0 landed
Avoid looping over all type cache entries in TypeCacheRelCallback()
- b85a9d046efd 18.0 landed
- c14d4acb8134 18.0 landed
Update header comment for lookup_type_cache()
- c1500a1ba7e1 18.0 landed
Revert: Avoid looping over all type cache entries in TypeCacheRelCallback()
- 8daa62a10c91 18.0 landed
Introduce hash_search_with_hash_value() function
- d0f020037e19 18.0 landed
Optimize InvalidateAttoptCacheCallback() and TypeCacheTypCallback()
- 40064a8ee1b3 18.0 landed
Refactor initial hash lookup in dynahash.c
- cc5ef90edd80 17.0 landed
Rationalize and improve error messages for some jsonpath items
- 92d2ab7554f9 17.0 cited
Avoid race in RelationBuildDesc() affecting CREATE INDEX CONCURRENTLY.
- fdd965d074d4 15.0 cited
Represent Lists as expansible arrays, not chains of cons-cells.
- 1cff1b95ab6d 13.0 cited

On Sun, Aug 25, 2024 at 10:00 PM Alexander Lakhin <exclusion@gmail.com> wrote:
> 22.08.2024 19:52, Alexander Korotkov wrotd:
> > If no objections, I'm planning to push this after reverting PARTITION
> > SPLIT/MERGE.
> >
>
> Please try to perform `make check` against a CLOBBER_CACHE_ALWAYS build.
> trilobite failed it:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=trilobite&dt=2024-08-25%2005%3A22%3A07
>
> and I'm observing the same locally:
> ...
> #5  0x00005636d37555f8 in ExceptionalCondition (conditionName=0x5636d39b1940 "found",
>      fileName=0x5636d39b1308 "typcache.c", lineNumber=3077) at assert.c:66
> #6  0x00005636d37554a4 in delete_rel_type_cache_if_needed (typentry=0x5636d41d5d10) at typcache.c:3077
> #7  0x00005636d3754063 in InvalidateCompositeTypeCacheEntry (typentry=0x5636d41d5d10) at typcache.c:2355
> #8  0x00005636d37541d3 in TypeCacheRelCallback (arg=0, relid=0) at typcache.c:2441
> ...
>
> (gdb) f 6
> #6  0x00005636d37554a4 in delete_rel_type_cache_if_needed (typentry=0x5636d41d5d10) at typcache.c:3077
> 3077                    Assert(found);
> (gdb) p found
> $1 = false
>
> (This Assert is introduced by c14d4acb8.)

Thank you for noticing.  I'm checking this.

------
Regards,
Alexander Korotkov
Supabase