On Sun, Oct 20, 2024 at 8:47 PM Alexander Korotkov <aekorotkov@gmail.com> wrote:
> On Tue, Oct 15, 2024 at 12:50 PM jian he <jian.universality@gmail.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.
------
Regards,
Alexander Korotkov
Supabase
