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.
