mirror of
https://github.com/MariaDB/server.git
synced 2025-10-03 06:19:16 +02:00
e151cb583d
In btr_search_info_update_hash, when hash potential is reset, make sure that AHI params are properly reset too. Before this changes, when cmp == 0, this assignment could be done if cursor.low_match == 0 and cursor.low_bytes == 0: info.left_bytes_field= 0x80010000; // 1-byte left prefix Since the code is not fully thread safe by design, another thread could have already taken the !n_hash_potential branch before, and got to where the potential of the hash is increased: info.n_hash_potential= ++n_hash_potential; If the reset to 0x80010000 happened right before the hash potential increment, then an AHI index with 1-byte left prefix could be later (possibly wrongly) built on the page. With this change, the assignment in case cmp == 0 becomes the same that the resetting code applied: info.left_bytes_field= 0x80000001; // 1-field left prefix This is more in-line pre-MDEV-35049 code behavior. A more coherent albeit possibly more costly solution would be to merge all the AHI "status" variables into one 64 bits atomic word, so that by design the above concurrency issues could not be applicable. Many thanks to Marko Mäkelä <marko.makela@mariadb.com> for spotting the relevant code and for the collaboration. |
||
|---|---|---|
| .. | ||
| btr0btr.cc | ||
| btr0bulk.cc | ||
| btr0cur.cc | ||
| btr0pcur.cc | ||
| btr0sea.cc | ||