Bug #81500 dead branch in search_key_in_table()

• Submitted: 19 May 2016 9:10
• Modified: 30 Apr 2018 11:20
• Reporter: Andrei Elkin
• Status: Closed
• Category: MySQL Server: Row Based Replication ( RBR )
• Severity: S3 (Non-critical)
• Version: 5.7+
• OS: Any
• CPU Architecture: Any

[19 May 2016 9:10] Andrei Elkin

Description:
The positive branch of

  if (key_type & UNIQUE_KEY_FLAG && table->s->uniques)
  {
    ...
  }

is never reached because the 2nd term of the conjunction is always
zero, per sources checking.

Running tests confirmed that.

The branch can be revived by leaving only the 1st term of the conjunction
for checking.
This change obviously would require performance assessment.

According to Guilhem the 5.6 may set the 2nd term to non-zero only
for internal optimizer tables.

How to repeat:
Check the sources, and run tests against the server patched
with assert(0) placed into the branch.

Suggested fix:
--- a/sql/log_event.cc
+++ b/sql/log_event.cc
@@ -9326,7 +9326,7 @@ search_key_in_table(TABLE *table, MY_BITMAP *bi_cols, uint key_type)
 
   DBUG_PRINT("debug", ("Unique keys count: %u", table->s->uniques));
 
-  if (key_type & UNIQUE_KEY_FLAG && table->s->uniques)
+  if (key_type & UNIQUE_KEY_FLAG)

[30 Apr 2018 11:20] Margaret Fisher

Posted by developer:
 
Changelog entry added for MySQL 8.0.12 and 5.7.23:
The slave_rows_search_algorithms system variable controls how rows are searched for matches when preparing batches of rows for row-based logging and replication. Specifying INDEX_SCAN as one of the search algorithms performs an index scan if an index is present. In the situation where a different primary key is used on the master and the slave, and a unique key is present on the slave, a bug in the code meant that the index scan was not being performed as it should be, and a slower table scan was being performed instead. The issue has now been corrected so that an index scan is used.