Re: HASH_FIXED_SIZE flag gets lost when attaching to existing hash table - Mailing list pgsql-hackers

From Tom Lane
Subject Re: HASH_FIXED_SIZE flag gets lost when attaching to existing hash table
Date
Msg-id 1671312.1753377875@sss.pgh.pa.us
Whole thread Raw
In response to HASH_FIXED_SIZE flag gets lost when attaching to existing hash table  (Aidar Imamov <a.imamov@postgrespro.ru>)
Responses Re: HASH_FIXED_SIZE flag gets lost when attaching to existing hash table
List pgsql-hackers
Aidar Imamov <a.imamov@postgrespro.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



pgsql-hackers by date:

Previous
From: Álvaro Herrera
Date:
Subject: Re: Commitfest 2025-03 still has active patches
Next
From: Tom Lane
Date:
Subject: Re: track generic and custom plans in pg_stat_statements