A fix and a test case for

Bug#41756 "Strange error messages about locks from InnoDB".
      
In JT_EQ_REF (join_read_key()) access method, 
don't try to unlock rows in the handler, unless certain that 
a) they were locked
b) they are not used.

Unlocking of rows is done by the logic of the nested join loop,
and is unaware of the possible caching that the access method may
have. This could lead to double unlocking, when a row
was unlocked first after reading into the cache, and then 
when taken from cache, as well as to unlocking of rows which
were actually used (but taken from cache).
      
Delegate part of the unlocking logic to the access method,
and in JT_EQ_REF count how many times a record was actually 
used in the join. Unlock it only if it's usage count is 0.

Implemented review comments.

1 files changed, 1 insertions, 0 deletions

diff --git a/sql/item_subselect.cc b/sql/item_subselect.cc
index 29db9eb0903..fa776ea3dca 100644
--- a/sql/item_subselect.cc
+++ b/sql/item_subselect.cc
@@ -1954,6 +1954,7 @@ int subselect_single_select_engine::exec()
               tab->read_record.record= tab->table->record[0];
               tab->read_record.thd= join->thd;
               tab->read_record.ref_length= tab->table->file->ref_length;
+              tab->read_record.unlock_row= rr_unlock_row;
               *(last_changed_tab++)= tab;
               break;
             }