On Sun, Oct 20, 2024 at 9:00 PM Alexander Korotkov <aekorot...@gmail.com> wrote: > 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.
Here you go. The test with injection point is implemented. ------ Regards, Alexander Korotkov Supabase
v15-0001-Update-header-comment-for-lookup_type_cache.patch
Description: Binary data
v15-0002-Avoid-looping-over-all-type-cache-entries-in-Typ.patch
Description: Binary data
