replace magic num in struct cachedesc with CATCACHE_MAXKEYS
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t50121psql -h localhost -U postgresBuilt from patchset v1 (message #1), September 20, 2026 at 04:20 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t50121_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t50121_1 && git checkout t50121_1Patchset v1 (message #1) is on t50121_1
Hi hackers,
I noticed that there is a magic number which can be replaced by CATCACHE_MAXKEYS
in struct cachedesc, I checked some other struct like CatCache, CatCTup, they
all use CATCACHE_MAXKEYS.
I did some search on pg-hackers, and found an old thread[0]/messages/by-id/603c8f071003281532t5e6c68eex458825485d4fcd98@mail.gmail.com that
Robert proposed to change
the maximum number of keys for a syscache from 4 to 5.
It seems to me that the *five-key syscaches* feature is not necessary
since the idea was
14 years old and we still use 4 keys without any problems(I might be wrong).
However, in that patch, there is a change that seems reasonable.
--- a/src/backend/utils/cache/syscache.c
+++ b/src/backend/utils/cache/syscache.c
@@ -95,7 +95,7 @@ struct cachedesc
Oid reloid; /* OID of the
relation being cached */
Oid indoid; /* OID of
index relation for this cache */
int nkeys; /* # of keys
needed for cache lookup */
- int key[4]; /* attribute
numbers of key attrs */
+ int key[CATCACHE_MAXKEYS]; /* attribute
numbers of key attrs */
int nbuckets; /* number of
hash buckets for this cache */
};
[0]: /messages/by-id/603c8f071003281532t5e6c68eex458825485d4fcd98@mail.gmail.com
--
Regards
Junwang Zhao
On 15.08.24 12:25, Junwang Zhao wrote:
I noticed that there is a magic number which can be replaced by CATCACHE_MAXKEYS
in struct cachedesc, I checked some other struct like CatCache, CatCTup, they
all use CATCACHE_MAXKEYS.
The "syscache" is the only user of the "catcache" right now. But I
think they are formally separate. So I don't think the "4" in the
syscache is necessarily the same as CATCACHE_MAXKEYS. For example,
increasing CATCACHE_MAXKEYS, hypothetically, wouldn't by itself make the
syscache support more than 4 keys.
On Fri, Aug 23, 2024 at 9:02 PM Peter Eisentraut <peter@eisentraut.org> wrote:
On 15.08.24 12:25, Junwang Zhao wrote:
I noticed that there is a magic number which can be replaced by CATCACHE_MAXKEYS
in struct cachedesc, I checked some other struct like CatCache, CatCTup, they
all use CATCACHE_MAXKEYS.The "syscache" is the only user of the "catcache" right now. But I
think they are formally separate. So I don't think the "4" in the
syscache is necessarily the same as CATCACHE_MAXKEYS. For example,
increasing CATCACHE_MAXKEYS, hypothetically, wouldn't by itself make the
syscache support more than 4 keys.
Thanks for your explanation.
CF status changed to withdrawn.
--
Regards
Junwang Zhao