Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.4(EOL), 10.5
-
None
Description
long uniques use internally Item_func_hash, which works as
longlong Item_func_hash::val_int()
|
{
|
DBUG_EXECUTE_IF("same_long_unique_hash", return 9;); |
unsigned_flag= true; |
ulong nr1= 1,nr2= 4;
|
...
|
cs->hash_sort(l, sizeof(l), &nr1, &nr2); |
...
|
return (longlong)nr1; |
}
|
But ulong has a different size on 32-bit and 64-bit. All other code that uses hash_sort(), seems to be using only the lower 32-bit of the returned hash value. This item uses all 64, which makes hash values dependent on whether the platform is 32-bit or 64-bit.
Considerations:
- a simple fix would be to use only the lowest 32 bit from nr1 in the Item_func_hash::val_int(), but perhaps this hash function should internally use uint32 and be changed everywhere?
- perhaps HA_HASH_FIELD_LENGTH should be 4 not 8?
- compatibility. how to fix it and not break existing tables?
Attachments
Issue Links
- is part of
-
MDEV-27653 long uniques don't work with unicode collations
- Closed
- relates to
-
MDEV-371 Unique indexes for blobs
- Closed
-
MDEV-27653 long uniques don't work with unicode collations
- Closed