Re: pg_verify_checksums failure with hash indexes

On Wed, Aug 29, 2018 at 3:39 PM, Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> On Tue, Aug 28, 2018 at 8:33 PM, Bernd Helmle <mailings(at)oopsware(dot)de> wrote:
>> Am Dienstag, den 28.08.2018, 11:21 +0200 schrieb Peter Eisentraut:
>>> This is reproducible with PG11 and PG12:
>>>
>>> initdb -k data
>>> postgres -D data
>>>
>>> make installcheck
>>> # shut down postgres with Ctrl-C
>>>
>>
>> I tried to reproduce this and by accident i had a blocksize=4 in my
>> configure script, and i got immediately failed installcheck results.
>> They seem hash index related and can easily be reproduced:
>>
>> SHOW block_size ;
>> block_size
>> ────────────
>> 4096
>>
>> CREATE TABLE foo(val text);
>> INSERT INTO foo VALUES('bernd');
>>
>> CREATE INDEX ON foo USING hash(val);
>> ERROR: index "foo_val_idx" contains corrupted page at block 0
>> HINT: Please REINDEX it.
>>
>> I have no idea wether this could be related, but i thought it won't
>> harm to share this here.
>>
>
> This issue seems different than the one got fixed in this thread. The
> reason for this issue is that the size of the hashm_mapp in
> HashMetaPageData is 4096, irrespective of the block size. So when the
> block size is big enough (i.e. 8192) then there is no problem, but
> when you set it to 4096, in that case, the hashm_mapp of the meta page
> is overwriting the special space of the meta page. That's the reason
> its showing corrupted page while checking the hash_page.

Just to verify this I just hacked it like below and it worked. I
think we need a more thoughtful value for HASH_MAX_BITMAPS.

diff --git a/src/include/access/hash.h b/src/include/access/hash.h
index 543d802..9909f69 100644
--- a/src/include/access/hash.h
+++ b/src/include/access/hash.h
@@ -232,7 +232,7 @@ typedef HashScanOpaqueData *HashScanOpaque;
* needing to fit into the metapage. (With 8K block size, 1024 bitmaps
* limit us to 256 GB of overflow space...)
*/
-#define HASH_MAX_BITMAPS 1024
+#define HASH_MAX_BITMAPS Min(BLCKSZ / 8, 1024)

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com