Re: type cache cleanup improvements

From: Alexander Korotkov <aekorotkov(at)gmail(dot)com>
To: Alexander Lakhin <exclusion(at)gmail(dot)com>
Cc: Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com>, Andrei Lepikhov <a(dot)lepikhov(at)postgrespro(dot)ru>, 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-08-25 21:22:03
Message-ID: CAPpHfduFDXgu3VCCWSPiiv+RKp3igO4PqPJOy_+Vf7mU3_n6iQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Aug 25, 2024 at 10:21 PM Alexander Korotkov
<aekorotkov(at)gmail(dot)com> wrote:
> On Sun, Aug 25, 2024 at 10:00 PM Alexander Lakhin <exclusion(at)gmail(dot)com> wrote:
> > 22.08.2024 19:52, Alexander Korotkov wrotd:
> > > If no objections, I'm planning to push this after reverting PARTITION
> > > SPLIT/MERGE.
> > >
> >
> > Please try to perform `make check` against a CLOBBER_CACHE_ALWAYS build.
> > trilobite failed it:
> > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=trilobite&dt=2024-08-25%2005%3A22%3A07
> >
> > and I'm observing the same locally:
> > ...
> > #5 0x00005636d37555f8 in ExceptionalCondition (conditionName=0x5636d39b1940 "found",
> > fileName=0x5636d39b1308 "typcache.c", lineNumber=3077) at assert.c:66
> > #6 0x00005636d37554a4 in delete_rel_type_cache_if_needed (typentry=0x5636d41d5d10) at typcache.c:3077
> > #7 0x00005636d3754063 in InvalidateCompositeTypeCacheEntry (typentry=0x5636d41d5d10) at typcache.c:2355
> > #8 0x00005636d37541d3 in TypeCacheRelCallback (arg=0, relid=0) at typcache.c:2441
> > ...
> >
> > (gdb) f 6
> > #6 0x00005636d37554a4 in delete_rel_type_cache_if_needed (typentry=0x5636d41d5d10) at typcache.c:3077
> > 3077 Assert(found);
> > (gdb) p found
> > $1 = false
> >
> > (This Assert is introduced by c14d4acb8.)
>
> Thank you for noticing. I'm checking this.

I didn't take into account that TypeCacheEntry could be invalidated
while lookup_type_cache() does syscache lookups. When I realized that
I was curious on how does it currently work. It appears that type
cache invalidation mostly only clears the flags while values are
remaining in place and still available for lookup_type_cache() caller.
TypeCacheEntry.tupDesc is invalidated directly, and it has guarantee
to survive only because we don't do any syscache lookups for composite
data types later in lookup_type_cache(). I'm becoming less fan of how
this works... I think these aspects needs to be at least documented
in details.

Regarding c14d4acb8, it appears to require redesign. I'm going to revert it.

------
Regards,
Alexander Korotkov
Supabase

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2024-08-25 23:05:46 Re: Interrupts vs signals
Previous Message Pavel Stehule 2024-08-25 19:49:24 Re: [PATCH] Add CANONICAL option to xmlserialize