tail heap hash found to be invalid on repeated DB loads

Eyal Rozenberg E.Rozenberg at cwi.nl
Thu Mar 29 00:37:11 CEST 2018

As part of, shall we say, helping with the QA of the 
March-feature-branch-based releases, I'm looking at some of the GDK code 
involving loading a BBP (and the action thereof).

Specifically, I've been looking at the function 
gdk/gdk_atoms.c:strCleanHash(), which recomputes the opportunistic 
partial hash table for a tail heap; checks if it's equal to what (seems 
to be) the hash loaded from disk; and if they don't match - copies the 
new hash over the old one.

I've added an indication in case the hashes don't match. And - I've 
noticed this happens repeatedly when trying to load the same database, 
even after previous plain vanilla unmodified source code runs, with no 
crashes and orderly shutdown. At least - I'm seeing this happen with 
11.29.1, and on a TPC-H SF 1 database I created with the script at 

My questions:

1. Is a discrepancy between the old and recomputed hash, when there had 
not been any problems on the previous run, expected behavior - or is it 
a bug?
2. If it is expected, why isn't a correct hash written back to the disk? 
Doesn't the memcmp(newhash, h->base, sizeof(newhash)) command 
eventually/immediately get translated into a write?
3. If this is not expected behavior - has this been verified not to 
happen on other machines? Other versions?
4. Could this be a 11.29.3 vs 11.29.1 issue somehow? I haven't updated 
to the latest RC yet.


More information about the developers-list mailing list