public inbox for [email protected]
help / color / mirror / Atom feedFrom: Andrei Lepikhov <[email protected]>
To: Alexander Korotkov <[email protected]>
Cc: Alexander Lakhin <[email protected]>
Cc: Pavel Borisov <[email protected]>
Cc: Teodor Sigaev <[email protected]>
Cc: Pgsql Hackers <[email protected]>
Cc: Aleksander Alekseev <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: Michael Paquier <[email protected]>
Subject: Re: type cache cleanup improvements
Date: Sat, 31 Aug 2024 21:33:23 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAPpHfdtkn=Q3JicCgoubDuty9f+V36=4zEsTSCVqE71XiwS8pQ@mail.gmail.com>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<CAPpHfdtNU6Lz21_ZtNDg_d+WoUvK3Togukp+cMu0cQp7o1w_OA@mail.gmail.com>
<CAPpHfdtaGKWoOtf7xAegjFbeu0We_eUkrh0Sg6BrCe0UUm3REw@mail.gmail.com>
<CALT9ZEFHxez3Y61nsV4tNK+=HdBqj4OeZQk0UOwecGWqFWnjbQ@mail.gmail.com>
<CAPpHfduEvD3ebSsQs80j10F_PS4FbukqXbPrhda=9KTk7X=LgA@mail.gmail.com>
<CALT9ZEEi2JuwQOBUDViTo-WkMsH-sKkLDWZS6XhTe6MnB-FhPw@mail.gmail.com>
<CAPpHfdvG-PzE5UN36my_4+FYv0n5rZJ-pN=z-gDCCk9ViPQ1Cw@mail.gmail.com>
<[email protected]>
<CAPpHfduPbcfQShtxGO72zr0+7EGKTob4HzQfUw7=3K3H5ZgqRw@mail.gmail.com>
<CAPpHfduFDXgu3VCCWSPiiv+RKp3igO4PqPJOy_+Vf7mU3_n6iQ@mail.gmail.com>
<[email protected]>
<CAPpHfdvYFxjsoRHiQb=pVoYuFogyw4Wd2W0f-c0sFwNLehmbbw@mail.gmail.com>
<CAPpHfdtkn=Q3JicCgoubDuty9f+V36=4zEsTSCVqE71XiwS8pQ@mail.gmail.com>
On 29/8/2024 11:01, Alexander Korotkov wrote:
> On Mon, Aug 26, 2024 at 11:26 AM Alexander Korotkov
>> Secondly, I'm not terribly happy with current state of type cache.
>> The caller of lookup_type_cache() might get already invalidated data.
>> This probably OK, because caller probably hold locks on dependent
>> objects to guarantee that relevant properties of type actually
>> persists. At very least this should be documented, but it doesn't
>> seem so. Setting of tupdesc is sensitive to its order of execution.
>> That feels quite fragile to me, and not documented either. I think
>> this area needs improvements before we push additional functionality
>> there.
>
> I see fdd965d074 added a proper handling for concurrent invalidation
> for relation cache. If a concurrent invalidation occurs, we retry
> building a relation descriptor. Thus, we end up with returning of a
> valid relation descriptor to caller. I wonder if we can take the same
> approach to type cache. That would make the whole type cache more
> consistent and less fragile. Also, this patch will be simpler.
I think I understand the solution from the commit fdd965d074.
Just for the record, you mentioned invalidation inside the
lookup_type_cache above. Passing through the code, I found the only
place for such a case - the call of the GetDefaultOpClass, which
triggers the opening of the relation pg_opclass, which can cause an
AcceptInvalidationMessages call. Did you mean this case, or does a wider
field of cases exist here?
--
regards, Andrei Lepikhov
view thread (28+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: type cache cleanup improvements
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox