From: | Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
---|---|
To: | jian he <jian(dot)universality(at)gmail(dot)com> |
Cc: | Artur Zakirov <zaartur(at)gmail(dot)com>, Andrei Lepikhov <lepihov(at)gmail(dot)com>, Alexander Lakhin <exclusion(at)gmail(dot)com>, Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com>, Teodor Sigaev <teodor(at)sigaev(dot)ru>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>, Aleksander Alekseev <aleksander(at)timescale(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Michael Paquier <michael(at)paquier(dot)xyz> |
Subject: | Re: type cache cleanup improvements |
Date: | 2024-10-20 18:00:18 |
Message-ID: | CAPpHfdt_dN5vyQQsTV=yeD+guDW7H7cvfkKj_mSETT0BEbyL+Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
------
Regards,
Alexander Korotkov
Supabase
From | Date | Subject | |
---|---|---|---|
Next Message | Michel Pelletier | 2024-10-20 18:25:30 | Re: Using Expanded Objects other than Arrays from plpgsql |
Previous Message | Alexander Korotkov | 2024-10-20 17:47:28 | Re: type cache cleanup improvements |