Re: type cache cleanup improvements

jian he <jian.universality@gmail.com>

From: jian he <jian.universality@gmail.com>

To: Alexander Korotkov <aekorotkov@gmail.com>

Cc: Artur Zakirov <zaartur@gmail.com>, Andrei Lepikhov <lepihov@gmail.com>, Alexander Lakhin <exclusion@gmail.com>, Pavel Borisov <pashkin.elfe@gmail.com>, 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-10-15T09:50:15Z

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 Tue, Oct 15, 2024 at 4:09 PM Alexander Korotkov <aekorotkov@gmail.com> wrote:
>
> Hi, Jian!
>
> Thank you for your review.
>
> On Tue, Oct 15, 2024 at 10:34 AM jian he <jian.universality@gmail.com> wrote:
> > I don't fully understand all of it. but I did some tests anyway.
> >
> > static void
> > cleanup_in_progress_typentries(void)
> > {
> >     int            i;
> >     if (in_progress_list_len > 1)
> >         elog(INFO, "%s:%d in_progress_list_len > 1", __FILE_NAME__, __LINE__);
> >     for (i = 0; i < in_progress_list_len; i++)
> >     {
> >         TypeCacheEntry *typentry;
> >         typentry = (TypeCacheEntry *) hash_search(TypeCacheHash,
> >                                                   &in_progress_list[i],
> >                                                   HASH_FIND, NULL);
> >         insert_rel_type_cache_if_needed(typentry);
> >     }
> >     in_progress_list_len = 0;
> > }
> >
> > the regress still passed.
> > I assume "elog(INFO, " won't interfere in cleanup_in_progress_typentries.
> > So we lack tests for larger in_progress_list_len values or i missed something?
>
> Try to run test suite with -DCLOBBER_CACHE_ALWAYS.
>

build from source, DCLOBBER_CACHE_ALWAYS takes a very long time.
So I gave up.


in lookup_type_cache, we unconditionally do
in_progress_list_len++;
in_progress_list_len--;

"static int    in_progress_list_len;"
means in_progress_list_len value change is confined in
src/backend/utils/cache/typcache.c.

based on above information, i am still  confused with
cleanup_in_progress_typentries, in_progress_list_len
is there any simple sql example to demo
cleanup_in_progress_typentries,  in_progress_list_len> 0.