Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit ac27c74

Browse files
author
Amit Kapila
committed
Fix the overrun in hash index metapage for smaller block sizes.
The commit 620b49a changed the value of HASH_MAX_BITMAPS with the intent to allow many non-unique values in hash indexes without worrying to reach the limit of the number of overflow pages. At that time, this didn't occur to us that it can overrun the block for smaller block sizes. Choose the value of HASH_MAX_BITMAPS based on BLCKSZ such that it gives the same answer as now for the cases where the overrun doesn't occur, and some other sufficiently-value for the cases where an overrun currently does occur. This allows us not to change the behavior in any case that currently works, so there's really no reason for a HASH_VERSION bump. Author: Dilip Kumar Reviewed-by: Amit Kapila Backpatch-through: 10 Discussion: https://postgr.es/m/CAA4eK1LtF4VmU4mx_+i72ff1MdNZ8XaJMGkt2HV8+uSWcn8t4A@mail.gmail.com
1 parent be54b37 commit ac27c74

File tree

1 file changed

+5
-2
lines changed

1 file changed

+5
-2
lines changed

src/include/access/hash.h

+5-2
Original file line numberDiff line numberDiff line change
@@ -230,9 +230,12 @@ typedef HashScanOpaqueData *HashScanOpaque;
230230
*
231231
* There is no particular upper limit on the size of mapp[], other than
232232
* needing to fit into the metapage. (With 8K block size, 1024 bitmaps
233-
* limit us to 256 GB of overflow space...)
233+
* limit us to 256 GB of overflow space...). For smaller block size we
234+
* can not use 1024 bitmaps as it will lead to the meta page data crossing
235+
* the block size boundary. So we use BLCKSZ to determine the maximum number
236+
* of bitmaps.
234237
*/
235-
#define HASH_MAX_BITMAPS 1024
238+
#define HASH_MAX_BITMAPS Min(BLCKSZ / 8, 1024)
236239

237240
#define HASH_SPLITPOINT_PHASE_BITS 2
238241
#define HASH_SPLITPOINT_PHASES_PER_GRP (1 << HASH_SPLITPOINT_PHASE_BITS)

0 commit comments

Comments
 (0)