Skip to content
  • Steinar H. Gunderson's avatar
    0baf57fb
    Bug #29329630: MAKE HASH_SORT CONSISTENTLY 64-BIT · 0baf57fb
    Steinar H. Gunderson authored
    Change hash_sort to take in and return uint64 instead of ulong, as ulong is
    32-bit on Windows, which gives us different hash values on different platforms.
    (MySQL Cluster also wants 64-bit hash values, regardless of platforms.) For
    code that needs stability on disk, so that hash values cannot change, we
    truncate to ulong on input and output. (This is safe; see the next paragraph.)
    
    Stability with previous versions have been verified by running the unit test
    against the current mysql-trunk, casting the expected result to ulong, both on
    Windows and on Linux. In addition, each hash function has been manually
    inspected to check that it either works in uint64 internally (the Unicode 9.0
    collations) or only propagates bits upwards (all other collations), which means
    that it doesn't matter whether we truncate during the computations or once at
    the end.
    
    Change-Id: I2ab1ca7554efb0c00eca73da0cb22fcf10f1e761
    (cherry picked from commit b03661eaae37429ef91a71906a0b5f52191b7dfd)
    0baf57fb
    Bug #29329630: MAKE HASH_SORT CONSISTENTLY 64-BIT
    Steinar H. Gunderson authored
    Change hash_sort to take in and return uint64 instead of ulong, as ulong is
    32-bit on Windows, which gives us different hash values on different platforms.
    (MySQL Cluster also wants 64-bit hash values, regardless of platforms.) For
    code that needs stability on disk, so that hash values cannot change, we
    truncate to ulong on input and output. (This is safe; see the next paragraph.)
    
    Stability with previous versions have been verified by running the unit test
    against the current mysql-trunk, casting the expected result to ulong, both on
    Windows and on Linux. In addition, each hash function has been manually
    inspected to check that it either works in uint64 internally (the Unicode 9.0
    collations) or only propagates bits upwards (all other collations), which means
    that it doesn't matter whether we truncate during the computations or once at
    the end.
    
    Change-Id: I2ab1ca7554efb0c00eca73da0cb22fcf10f1e761
    (cherry picked from commit b03661eaae37429ef91a71906a0b5f52191b7dfd)
Loading