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.

mysql-test/r/innodb_lock_wait_timeout_1.result:
  Update results (Bug41756).
mysql-test/t/innodb_lock_wait_timeout_1.test:
  Add a test case (Bug#41756).
sql/item_subselect.cc:
  Complete struct READ_RECORD initialization with a new
  member to unlock records.
sql/records.cc:
  Extend READ_RECORD API with a method to unlock read records.
sql/sql_select.cc:
  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.
sql/sql_select.h:
  Add members to TABLE_REF to count TABLE_REF buffer usage count.
sql/structs.h:
  Update declarations.

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.


mysql-test/r/bug41756.result:
  Add result file (Bug#41756)
mysql-test/t/bug41756-master.opt:
  Use --innodb-locks-unsafe-for-binlog, as in 5.0 just
  using read_committed isolation is not sufficient to 
  reproduce the bug.
mysql-test/t/bug41756.test:
  Add a test file (Bug#41756)
sql/item_subselect.cc:
  Complete struct READ_RECORD initialization with a new
  member to unlock records.
sql/records.cc:
  Extend READ_RECORD API with a method to unlock read records.
sql/sql_select.cc:
  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.
sql/sql_select.h:
  Add members to TABLE_REF to count TABLE_REF buffer usage count.
sql/structs.h:
  Update declarations.

- re-enabled main.innodb_bug44369;
- re-enabled main.innodb_bug47777;
- re-enabled innodb.innodb_information_schema.

            values return too many records

WHERE clauses with "outer_value_list NOT IN subselect" were
handled incorrectly if the outer value list contained multiple 
items where at least one of these could be NULL. The first 
outer record with NULL value was handled correctly, but if a 
second record with NULL value existed, the optimizer would 
choose to reuse the result it got on the last execution of the 
subselect. This is incorrect if the outer value list has 
multiple items.
     
The fix is to make Item_in_optimizer::val_int (in 
item_cmpfunc.cc) reuse the result of the latest execution
for NULL values only if all values in the outer_value_list 
are NULL.


mysql-test/r/subselect3.result:
  Added test for BUG#48177
mysql-test/t/subselect3.test:
  Added test for BUG#48177
sql/item_cmpfunc.cc:
  Make Item_in_optimizer::val_int (in item_cmpfunc.cc) reuse the result of the latest execution for NULL values only if all values in the outer_value_list are NULL.

Detailed revision comments:

r6126 | vasil | 2009-10-30 10:36:07 +0200 (Fri, 30 Oct 2009) | 45 lines
branches/zip: Merge r6112:6125 from branches/5.1:

(skipping r6122 and r6123, Jimmy says these are already present and need
not be merged):

  ------------------------------------------------------------------------
  r6122 | jyang | 2009-10-30 05:18:38 +0200 (Fri, 30 Oct 2009) | 7 lines
  Changed paths:
     M /branches/5.1/handler/ha_innodb.cc
     M /branches/5.1/mysql-test/innodb_bug44369.result
     M /branches/5.1/mysql-test/innodb_bug44369.test
     M /branches/5.1/mysql-test/innodb_bug46000.result
     M /branches/5.1/mysql-test/innodb_bug46000.test
  
  branches/5.1: Chnage WARN_LEVEL_ERROR to WARN_LEVEL_WARN
  for push_warning_printf() call in innodb.
  Fix Bug#47233: Innodb calls push_warning(MYSQL_ERROR::WARN_LEVEL_ERROR)
  
  rb://170 approved by Marko.
  
  
  ------------------------------------------------------------------------
  r6123 | jyang | 2009-10-30 05:43:06 +0200 (Fri, 30 Oct 2009) | 8 lines
  Changed paths:
     M /branches/5.1/os/os0proc.c
  
  branches/5.1: In os_mem_alloc_large(), if we fail to attach
  the shared memory, reset memory pointer ptr to NULL, and
  allocate memory from conventional pool. This is a port
  from branches/zip.
  Bug #48237 Error handling in os_mem_alloc_large appears to be incorrect
  rb://198  Approved by: Marko
  
  
  ------------------------------------------------------------------------
  r6125 | vasil | 2009-10-30 10:31:23 +0200 (Fri, 30 Oct 2009) | 4 lines
  Changed paths:
     M /branches/5.1/handler/ha_innodb.cc
  
  branches/5.1:
  
  White-space fixup.
  
  ------------------------------------------------------------------------

Detailed revision comments:

r6121 | sunny | 2009-10-30 01:42:11 +0200 (Fri, 30 Oct 2009) | 7 lines
branches/zip: This test has been problematic for sometime now. The underlying
bug is that the data dictionaries get out of sync. In the AUTOINC code we
try and apply salve to the symptoms. In the past MySQL made some unrelated
change and the dictionaries stopped getting out of sync and this test started
to fail. Now, it seems they have reverted that changed and the test is
passing again. I suspect this is not he last time that this test will change.

r6124 | jyang | 2009-10-30 10:02:31 +0200 (Fri, 30 Oct 2009) | 5 lines
branches/zip: Correct the bug number for -r6109 change
from # 48273 to #48237

Detailed revision comments:

r6114 | vasil | 2009-10-29 18:43:51 +0200 (Thu, 29 Oct 2009) | 6 lines
branches/zip:

* Add ChangeLog entries for latest changes
* Obey alphabetical order in the list of the files
* White-space fixup

Detailed revision comments:

r6113 | vasil | 2009-10-29 18:15:50 +0200 (Thu, 29 Oct 2009) | 93 lines
branches/zip: Merge r5912:6112 from branches/5.1:

(after this merge the innodb-autoinc test starts to fail, but
I commit anyway because it would be easier to investigate the
failure this way)

  ------------------------------------------------------------------------
  r5952 | calvin | 2009-09-22 19:45:07 +0300 (Tue, 22 Sep 2009) | 7 lines
  Changed paths:
     M /branches/5.1/handler/ha_innodb.cc
  
  branches/5.1: fix bug#42383: Can't create table 'test.bug39438'
  
  For embedded server, MySQL may pass in full path, which is
  currently disallowed. It is needed to relax the condition by
  accepting full paths in the embedded case.
  
  Approved by: Heikki (on IM)
  ------------------------------------------------------------------------
  r6032 | vasil | 2009-10-01 15:55:49 +0300 (Thu, 01 Oct 2009) | 8 lines
  Changed paths:
     M /branches/5.1/handler/ha_innodb.cc
  
  branches/5.1:
  
  Fix Bug#38996 Race condition in ANALYZE TABLE
  
  by serializing ANALYZE TABLE inside InnoDB.
  
  Approved by:	Heikki (rb://175)
  
  ------------------------------------------------------------------------
  r6045 | jyang | 2009-10-08 02:27:08 +0300 (Thu, 08 Oct 2009) | 7 lines
  Changed paths:
     M /branches/5.1/handler/ha_innodb.cc
     A /branches/5.1/mysql-test/innodb_bug47777.result
     A /branches/5.1/mysql-test/innodb_bug47777.test
  
  branches/5.1: Fix bug #47777. Treat the Geometry data same as
  Binary BLOB in ha_innobase::store_key_val_for_row(), since the
  Geometry data is stored as Binary BLOB in Innodb.
  
  Review: rb://180 approved by Marko Makela.
  
  
  ------------------------------------------------------------------------
  r6051 | sunny | 2009-10-12 07:05:00 +0300 (Mon, 12 Oct 2009) | 6 lines
  Changed paths:
     M /branches/5.1/handler/ha_innodb.cc
     M /branches/5.1/mysql-test/innodb-autoinc.result
     M /branches/5.1/mysql-test/innodb-autoinc.test
  
  branches/5.1: Ignore negative values supplied by the user when calculating the
  next value to store in dict_table_t. Setting autoincrement columns top negative
  values is undefined behavior and this change should bring the behavior of
  InnoDB closer to what users expect. Added several tests to check.
  rb://162
  
  ------------------------------------------------------------------------
  r6052 | sunny | 2009-10-12 07:09:56 +0300 (Mon, 12 Oct 2009) | 4 lines
  Changed paths:
     M /branches/5.1/handler/ha_innodb.cc
     M /branches/5.1/mysql-test/innodb-autoinc.result
     M /branches/5.1/mysql-test/innodb-autoinc.test
  
  branches/5.1: Reset the statement level autoinc counter on ROLLBACK. Fix
  the test results too.
  rb://164
  
  ------------------------------------------------------------------------
  r6053 | sunny | 2009-10-12 07:37:49 +0300 (Mon, 12 Oct 2009) | 6 lines
  Changed paths:
     M /branches/5.1/handler/ha_innodb.cc
     M /branches/5.1/mysql-test/innodb-autoinc.result
     M /branches/5.1/mysql-test/innodb-autoinc.test
  
  branches/5.1: Copy the maximum AUTOINC value from the old table to the new
  table when MySQL does a CREATE INDEX ON T. This is required because MySQL
  does a table copy, rename and drops the old table.
  Fix Bug#47125: auto_increment start value is ignored if an index is created and engine=innodb
  rb://168
  
  ------------------------------------------------------------------------
  r6076 | vasil | 2009-10-14 19:30:12 +0300 (Wed, 14 Oct 2009) | 4 lines
  Changed paths:
     M /branches/5.1/row/row0mysql.c
  
  branches/5.1:
  
  Fix typo.
  
  ------------------------------------------------------------------------

Detailed revision comments:

r6112 | calvin | 2009-10-29 16:21:15 +0200 (Thu, 29 Oct 2009) | 4 lines
branches/zip: consideration for icc compilers

Proposed by MySQL, and approved by Marko.