Replication breaks with HA_ERR_KEY_NOT_FOUND (INDEX_SCAN,HASH_SCAN)

Conclusion:

HASH_SCAN is not designed to handle cases where multiple updates targeted at the same row during replication and has the following issues.

So, it is recommended to use slave_rows_search_algorithms='INDEX_SCAN,TABLE_SCAN' with an explicit primary key in the table as a workaround.

Submitted the findings and the patch as contribution to upstream via https://bugs.mysql.com/bug.php?id=115741

Thanks for the suggestion, . I’ve addressed your suggestions.

1. Done.

2. Modified the container to vector instead of a list. But, the number of items to be inserted into the vector is unknown beforehand because there can be any number of duplicates. So, I’ve updated the iterator to an index to access the vector.

3. Done.

Draft PR created.

Looks absolutely great.

However, I have a few suggestions for further improvements (sorry ):

1. We can change std::set<uchar *, Key_compare> m_distinct_keys to std::unordered_set<uchar *, Key_hash_functor, Key_equality_functor> m_distinct_keys. As the only functionality we need from this container is finding if a key already exists, unordered version of the container will suite much better here. Although you will need to write your own Key_hash_functor and Key_equality_functor (similarly to Key_compare).

2. It would be great if we could change std::list<uchar *> m_distinct_keys_list; to std::vecttor. However, we should be more careful here, as inserting into this container may invalidate iterators (m_distinct_keys_list_itr). We can do this only when we can know the number of items to be inserted in advance. In this case we will be able to call reserve() method on this container and will guarantee that push_back()s will not cause memory reallocation and invalidating iterators. If this is not possible, I would suggest to change m_distinct_keys_list_itr to a simple index in this vector std::size_t m_distinct_key_idx

3. You can simplify the logic of inserting into m_distinct_keys: just simply do the call to insert() and check the boolean from the returned pair. You do not have to call find() first.

I think at this point it makes sense to create a draft PR for this bug.

Thanks for the suggestion . A simple change can be done to use a linear list along with the existing unordered_set will fix this corner case.

The set can just be used to check for duplicates while inserting and the list can be used to used later to traverse the keys in the original order.