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