Conflicts
=========
Text conflict in sql/repl_failsafe.cc

Additional changes
==================
Replace references to pthread_mutex with mysql_mutex

fails in PB sporadically)
      
The IO thread can concurrently access the relay log IO_CACHE
while another thread is performing an FLUSH LOGS procedure.
      
FLUSH LOGS closes and reopens the relay log and while doing so it
(re)initializes its IO_CACHE. During this procedure the IO_CACHE
mutex is also reinitialized, which can cause problems if some
other thread (namely the IO THREAD) is concurrently accessing it
at the time .
      
This patch fixes the problem by extending the interface of the
flush_master_info function to also include a second paramater, 
"need_relay_log_lock", stating whether the thread should grab the 
relay log lock or not before actually flushing the relay log. 
Also, IO thread now calls flush_master_info with this flag set 
when it flushes master info with in the event read_event loop.

Finally, we also increase loop time in rpl_heartbeat_basic test 
case, so that the number of calls to flush logs doubles, stressing
this part of the code a little more.

The root cause of the crash is that a TranxNode is freed before it is used.
A TranxNode is allocated and inserted into the active list each time 
a log event is written and flushed into the binlog file. 
The memory for TranxNode is allocated with thd_alloc and will be freed 
at the end of the statement. The after_commit/after_rollback callback
was supposed to be called before the end of each statement and remove the node from
the active list. However this assumption is not correct in all cases(e.g. call 
'CREATE TEMPORARY TABLE myisam_t SELECT * FROM innodb_t' in a transaction
 and delete all temporary tables automatically when a session closed), 
and can cause the memory allocated for TranxNode be freed
before it was removed from the active list. So The TranxNode pointer in the active
list would become a wild pointer and cause the crash.

After this patch, We have a class called a TranxNodeAllocate which manages the memory
for allocating and freeing TranxNode. It uses my_malloc to allocate memory.

The auto-inc unsafe warning makes sense even though it's just
one auto-inc table could be involved via a trigger or a stored
function.
However its content was not updated by bug@45677 fixes continuing to mention
two tables whereas the fixes refined semantics of replication of auto_increment 
in stored routine.

Fixed with updating the error message, renaming the error and an internal unsafe-condition 
constants.

A documentation notice
======================

      Inserting into an autoincrement column in a stored function or a trigger
      is unsafe for replication.
      Even with just one autoincrement column, if the routine is invoked more than 
      once slave is not guaranteed to execute the statement graph same way as 
      the master.
      And since it's impossible to estimate how many times a routine can be invoked at 
      the query pre-execution phase (see lock_tables), the statement is marked
      pessimistically unsafe. 

------------------------------------------------------------
revno: 2630.22.42
committer: Konstantin Osipov <kostja@sun.com>
branch nick: mysql-6.0-runtime
timestamp: Fri 2008-10-17 14:36:55 +0400
message:
  Update old wording (table engine -> storage engine).

      
It is well-known that due to concurrency issues, a slave can become
inconsistent when a transaction contains updates to both transaction and
non-transactional tables.
                    
In a nutshell, the current code-base tries to preserve causality among the
statements by writing non-transactional statements to the txn-cache which
is flushed upon commit. However, modifications done to non-transactional
tables on behalf of a transaction become immediately visible to other
connections but may not immediately get into the binary log and therefore
consistency may be broken.
            
In general, it is impossible to automatically detect causality/dependency
among statements by just analyzing the statements sent to the server. This
happen because dependency may be hidden in the application code and it is
necessary to know a priori all the statements processed in the context of
a transaction such as in a procedure. Moreover, even for the few cases that
we could automatically address in the server, the computation effort
required could make the approach infeasible.
            
So, in this patch we introduce the option
      - "--binlog-direct-non-transactional-updates" that can be used to bypass
      the current behavior in order to write directly to binary log statements
      that change non-transactional tables.

Besides, it is used to enable the WL#2687 which is disabled by default.

      
It is well-known that due to concurrency issues, a slave can become
inconsistent when a transaction contains updates to both transaction and
non-transactional tables.
                    
In a nutshell, the current code-base tries to preserve causality among the
statements by writing non-transactional statements to the txn-cache which
is flushed upon commit. However, modifications done to non-transactional
tables on behalf of a transaction become immediately visible to other
connections but may not immediately get into the binary log and therefore
consistency may be broken.
            
In general, it is impossible to automatically detect causality/dependency
among statements by just analyzing the statements sent to the server. This
happen because dependency may be hidden in the application code and it is
necessary to know a priori all the statements processed in the context of
a transaction such as in a procedure. Moreover, even for the few cases that
we could automatically address in the server, the computation effort
required could make the approach infeasible.
            
So, in this patch we introduce the option
      - "--binlog-direct-non-transactional-updates" that can be used to bypass
      the current behavior in order to write directly to binary log statements
      that change non-transactional tables.

Besides, it is used to enable the WL#2687 which is disabled by default.

in errmsg.txt. Kept the one in that matched the location
in errmsg-utf8.txt, ie after ER_UNKNOWN_LOCALE.

The reason for the crash is using uinitialized mutex attribute (MY_MUTEX_FAST_INIT)
in pthread_mutex_init.

The fix is to initialize the attribute before the first use.