Re: type cache cleanup improvements

Alexander Korotkov <aekorotkov@gmail.com>

From: Alexander Korotkov <aekorotkov@gmail.com>

To: Noah Misch <noah@leadboat.com>

Cc: Pavel Borisov <pashkin.elfe@gmail.com>, Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>, Andrei Lepikhov <lepihov@gmail.com>, jian he <jian.universality@gmail.com>, Artur Zakirov <zaartur@gmail.com>, Alexander Lakhin <exclusion@gmail.com>, Teodor Sigaev <teodor@sigaev.ru>, Pgsql Hackers <pgsql-hackers@postgresql.org>, Aleksander Alekseev <aleksander@timescale.com>, Tom Lane <tgl@sss.pgh.pa.us>, Michael Paquier <michael@paquier.xyz>

Date: 2025-04-21T01:54:08Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Maintain RelIdToTypeIdCacheHash in TypeCacheOpcCallback()
- bb78e4267817 18.0 landed
Fix concurrrently in typcache_rel_type_cache.sql
- aa1e898dea66 18.0 landed
Avoid looping over all type cache entries in TypeCacheRelCallback()
- b85a9d046efd 18.0 landed
- c14d4acb8134 18.0 landed
Update header comment for lookup_type_cache()
- c1500a1ba7e1 18.0 landed
Revert: Avoid looping over all type cache entries in TypeCacheRelCallback()
- 8daa62a10c91 18.0 landed
Introduce hash_search_with_hash_value() function
- d0f020037e19 18.0 landed
Optimize InvalidateAttoptCacheCallback() and TypeCacheTypCallback()
- 40064a8ee1b3 18.0 landed
Refactor initial hash lookup in dynahash.c
- cc5ef90edd80 17.0 landed
Rationalize and improve error messages for some jsonpath items
- 92d2ab7554f9 17.0 cited
Avoid race in RelationBuildDesc() affecting CREATE INDEX CONCURRENTLY.
- fdd965d074d4 15.0 cited
Represent Lists as expansible arrays, not chains of cons-cells.
- 1cff1b95ab6d 13.0 cited

Attachments

v1-0001-Maintain-RelIdToTypeIdCacheHash-in-TypeCacheOpcCa.patch (application/octet-stream) patch v1-0001

Hi, Noah!

On Sat, Apr 12, 2025 at 12:43 AM Alexander Korotkov
<aekorotkov@gmail.com> wrote:
>
> On Fri, Apr 11, 2025 at 11:32 PM Noah Misch <noah@leadboat.com> wrote:
> >
> > On Tue, Oct 22, 2024 at 08:33:24PM +0300, Alexander Korotkov wrote:
> > > On Tue, Oct 22, 2024 at 6:10 PM Pavel Borisov <pashkin.elfe@gmail.com> wrote:
> > > > On Tue, 22 Oct 2024 at 11:34, Alexander Korotkov <aekorotkov@gmail.com> wrote:
> > > >> I'm going to push this if no objections.
> >
> > (This became commit b85a9d0.)
> >
> > > +     /* Call delete_rel_type_cache() if we actually cleared something */
> > > +     if (hadTupDescOrOpclass)
> > > +             delete_rel_type_cache_if_needed(typentry);
> >
> > I think the intent was to maintain the invariant that a RelIdToTypeIdCacheHash
> > entry exists if and only if certain kinds of data appear in the TypeCacheHash
> > entry.  However, TypeCacheOpcCallback() clears TCFLAGS_OPERATOR_FLAGS without
> > maintaining RelIdToTypeIdCacheHash.  Is it right to do that?
>
> Thank you for the question.  I'll recheck this in next couple of days.

Sorry for the delay.  Generally, your finding is correct.  But, I
didn't manage to reproduce the situation, where existing code leads to
real error.  In order to have it, we must have typcache entry without
TCFLAGS_HAVE_PG_TYPE_DATA and tupDesc, but with some of
TCFLAGS_OPERATOR_FLAGS.  Reseting TCFLAGS_HAVE_PG_TYPE_DATA for a
composite type doesn't seem to be possible without resetting the rest
at the same time.

Nevertheless, I think it would be fragile to leave the current code
"as is".  If even there is no case of real error (or it's just me
didn't manage to find it), it could appear after further changes of
type cache code.  So, the fix is attached.

------
Regards,
Alexander Korotkov
Supabase