Re: type cache cleanup improvements

On Sun, Oct 20, 2024 at 9:00 PM Alexander Korotkov <aekorotkov(at)gmail(dot)com> wrote:
> On Sun, Oct 20, 2024 at 8:47 PM Alexander Korotkov <aekorotkov(at)gmail(dot)com> wrote:
> > On Tue, Oct 15, 2024 at 12:50 PM jian he <jian(dot)universality(at)gmail(dot)com> wrote:
> > > 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--;
> >
> > Yes, this should work OK when no errors. On error or interruption,
> > finalize_in_progress_typentries() will clean the things up.
> >
> > > "static int in_progress_list_len;"
> > > means in_progress_list_len value change is confined in
> > > src/backend/utils/cache/typcache.c.
> >
> > Yep.
> >
> > > 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.
> >
> > I don't think there is simple sql to reliably reproduce that. In
> > order to hit that, we must process invalidation messages in some
> > (short) moment of time during lookup_type_cache(). You can reproduce
> > that by setting a breakpoint in lookup_type_cache() and in parallel do
> > something to invalidate the type cache entry (for instance, ALTER
> > TABLE ... ADD COLUMN ... would invalidate the composite type).
>
> Oops, concurrent invalidation message is not enough here. So,
> -DCLOBBER_CACHE_ALWAYS is also not enough to reproduce the situation.
> Injection-point test is required. I'm going to add this.

Here you go. The test with injection point is implemented.

------
Regards,
Alexander Korotkov
Supabase