From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Aidar Imamov <a(dot)imamov(at)postgrespro(dot)ru> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: HASH_FIXED_SIZE flag gets lost when attaching to existing hash table |
Date: | 2025-07-24 17:24:35 |
Message-ID: | 1671312.1753377875@sss.pgh.pa.us |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Aidar Imamov <a(dot)imamov(at)postgrespro(dot)ru> writes:
> Recently, while working with hash tables in dynahash.c, I noticed
> something weird.
> When a hash table is already created in shared memory, and the another
> process
> calls hash_create attempting to attach to it, it seems like the
> HASH_FIXED_SIZE
> flag gets lost.
Yeah, you are right. This seems to be an oversight in 7c797e719
which introduced that flag. It only affects predicate-lock tables
because we don't use HASH_FIXED_SIZE anywhere else, and it'd only
matter in EXEC_BACKEND builds, so it's not that surprising that
nobody noticed. But we ought to fix it going forward.
I don't really like your solution though. ISTM the intent of the
code is that if the shared hashtable already exists, we adhere to the
properties it has, we don't rely on the current caller to specify the
exact same values. So relying on the caller to get HASH_FIXED_SIZE
correct here seems like the wrong thing. I think we ought to add
an isfixed flag to the shared hashtable header and copy that.
(IOW, isfixed ought to act more like keysize/ssize/sshift, and should
perhaps be grouped with them.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2025-07-24 17:43:47 | Re: track generic and custom plans in pg_stat_statements |
Previous Message | Álvaro Herrera | 2025-07-24 16:58:24 | Re: Commitfest 2025-03 still has active patches |