merging from 5.1 to rep+2 starting at gca(5.1, next-mr) == build@mysql.com-20091104182209-iui387z35159aoyw

NOTE: backporting BUG#42150 into next-mr
      Includes latest Andrei's patch (see [2 Feb 18:40] Bugs System)
      and merge.test post-push fix (see [3 Feb 18:04] Bugs System)

The reason of the bug appeared to be overreacting on absense of a
binlog file although the file name had been presented in in the master
binlog index file.
By convention, there should have been only a warning printed and the rest of
`reset master' logics completed.  This did not happen on windows
due to incorrect value of my_errno returned from nt_share_delete().
      
Fixed with correcting my_errno assignment in nt_share_delete() to be ENOENT in 
he event of no binlog file. Some minor refactoring has been made.

beyond unsigned long.
BUG#44779: binlog.binlog_max_extension may be causing failure on 
next test in PB
            
NOTE1: this is the backport to next-mr.
NOTE2: already includes patch for BUG#44779.
            
Binlog file extensions would turn into negative numbers once the
variable used to hold the value reached maximum for signed
long. Consequently, incrementing value to the next (negative) number
would lead to .000000 extension, causing the server to fail.
                        
This patch addresses this issue by not allowing negative extensions
and by returning an error on find_uniq_filename, when the limit is
reached. Additionally, warnings are printed to the error log when the
limit is approaching. FLUSH LOGS will also report warnings to the
user, if the extension number has reached the limit. The limit has been
set to 0x7FFFFFFF as the maximum.

The mentioned on the bug report set of bugs fixes have not be pushed to the main trees.

Fixed with extracting commits done to 6.0-rpl tree and applying them to the main 5.1.
Notes.
1. part of changes - the mtr's specific - were packported to the main 5.0 tree for mtr v1
   as http://lists.mysql.com/commits/46562
   However, there is no that fix anymore in the mtr v2. (This fact was mailed to mtr maintaining
   people).

2. Bug@36929  crash in kill_zombie_dump_threads-> THD::awake() with replication tests
   is not backported because the base code of the patch is libevent and that was removed
   from the main trees due to its instability.

Post-push fix: Removed MTRv1 arguments according to the
original patch. Although there is a version check, the patch
was pushed to a 5.1 GA staging tree, while the version check 
considers version 5.2. This makes the deprecated parameters 
to be used, despite the fact that they are not valid anymore.

Part of MTRv1 is currently used in RQG semisync test, and this
was causing the test to fail on slave startup.

It should be safe to uncomment when merging up to celosia.

After fix of bug46322, logging to table is turned off, each test
that need this should turn on it in it's opt file.

Add suppression to unsafe statement warnings for binlog_unsafe.test.

      
Replication info files are not being flushed and synced when the
command 'STOP SLAVE' is issued. This means that one cannot just
rely on existing values on those files when the slave has been
stopped. Having consistent, uncorrupted and up-to-date info files
when stopping the slave would be most useful, for instance, for
snapshotting purposes (a procedure that is often used for
restoring slaves).
      
This patch addresses this by instrumenting the
terminate_slave_threads function so that it also flushes and
syncs the *info files as well as the relay log whenever it gets
called, ie, on 'STOP SLAVE'.  Although this imposes a performance
trade-off (specifically when stopping the slave), it should have
no negative influence on overall replication performance (impact
is only noticeable on 'STOP SLAVE').

Post-push fix: Reverting change in Makefile.am which was
causing windows not to build client/.

CONFLICTS
=========

Text conflict in sql/sql_yacc.yy
1 conflicts encountered. 

      
One statement that have more than one different tables to update with 
autoinc columns just was marked as unsafe in mixed mode, so the unsafe 
warning can't be produced in statement mode.
      
To fix the problem, mark the statement as unsafe in statement mode too.

Create a set of test cases to see if some DDL statements implicitly commit
a transaction on the NDB and are written directly to the binary log without
going through either the Statement- or Transactional-Cache.

Removed test case that was left without significance after
backporting the deprecated constructs from 6.0 codebase.

merging 5.1 main -> 5.1-rep+2 -> 5.1-rep+3; binlog_unsafe , rpl_mysql_upgrade fail and are under treatment

NOTE: Backport of:

bzr log -r revid:sp1r-serg@sergbook.mysql.com-20070505200319-38337
------------------------------------------------------------
revno: 2469.263.4
committer: serg@sergbook.mysql.com
timestamp: Sat 2007-05-05 13:03:19 -0700
message:
  Removing deprecated features:
  --master-XXX command-line options
  log_bin_trust_routine_creators
  table_type
  BACKUP TABLE ...
  RESTORE TABLE ...
  SHOW PLUGIN
  LOAD TABLE ... FROM MASTER
  LOAD DATA FROM MASTER
  SHOW INNODB STATUS
  SHOW MUTEX STATUS
  SHOW TABLE TYPES
  ... TIMESTAMP(N)
  ... TYPE=engine
  
  RESET SLAVE don't reset connection parameters anymore
  LOAD DATA: check opt_secure_file_priv before access(filename)
  improved WARN_DEPRECATED macro

Non-transactional updates that take place inside a transaction present problems
for logging because they are visible to other clients before the transaction
is committed, and they are not rolled back even if the transaction is rolled
back. It is not always possible to log correctly in statement format when both
transactional and non-transactional tables are used in the same transaction.

In the current patch, we ensure that such scenario is completely safe under the
ROW and MIXED modes.

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.

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.

- 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.

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.
  
  ------------------------------------------------------------------------