Text conflict in mysql-test/collections/default.experimental
Text conflict in mysql-test/r/show_check.result
Text conflict in mysql-test/r/sp-code.result
Text conflict in mysql-test/suite/binlog/r/binlog_tmp_table.result
Text conflict in mysql-test/suite/rpl/t/disabled.def
Text conflict in mysql-test/t/show_check.test
Text conflict in mysys/my_delete.c
Text conflict in sql/item.h
Text conflict in sql/item_cmpfunc.h
Text conflict in sql/log.cc
Text conflict in sql/mysqld.cc
Text conflict in sql/repl_failsafe.cc
Text conflict in sql/slave.cc
Text conflict in sql/sql_parse.cc
Text conflict in sql/sql_table.cc
Text conflict in sql/sql_yacc.yy
Text conflict in storage/myisam/ha_myisam.cc

Corrected results for
 stm_auto_increment_bug33029.reject      2009-12-01
		20:01:49.000000000 +0300
       <andrei> @@ -42,9 +42,6 @@
       <andrei>  RETURN i;
       <andrei>  END//
       <andrei>  CALL p1();
       <andrei> -Warnings:
       <andrei> -Note   1592    Statement may not be safe to log in statement
		format.
       <andrei> -Note   1592    Statement may not be safe to log in statement
		format.

There should be indeed no Note present because there is in fact autoincrement 
top-level query in sp() that triggers inserting in yet another auto-inc table.
(todo: alert DaoGang to improve the test).

mysqld crashed in network_init()).

The problem was that current_thd was not ready at that point in mysqld life,
so ER() macro could not be used.

The fix is to use ER_DEFAULT() macro, which is intented for such cases.

Part 1: Instrumentation interface

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

The following 6.0 revisions were analyzed:
  - sp1r-brian@zim.(none)-20071228102738-21894
  - sp1r-brian@zim.(none)-20071228121841-56447
  - sp1r-brian@zim.(none)-20071228205403-56423
  - sp1r-brian@zim.(none)-20071228221139-55341
  - sp1r-brian@zim.(none)-20071228233443-55352
  - sp1r-brian@zim.(none)-20071229094527-61763
  - sp1r-brian@zim.(none)-20071230203739-61746
  - sp1r-brian@zim.(none)-20080102213805-61741
  - sp1r-brian@zim.(none)-20080103201041-61746
  - sp1r-brian@zim.(none)-20080104234927-59875
  - sp1r-brian@zim.(none)-20080105005827-59874
  - sp1r-brian@zim.(none)-20080105012020-59865
  - sp1r-brian@zim.(none)-20080106003858-59857
  - sp1r-brian@zim.(none)-20080123195552-31680
  - sp1r-brian@zim.(none)-20080124201848-29999
  - sp1r-brian@zim.(none)-20080129075144-36991
  - sp1r-cbell/Chuck@mysql_cab_desk.-20080215041806-21954
  - sp1r-vvaintroub@wva.-20080212124547-06272
  - sp1r-dfischer/mysqldev@mysql.com/production.mysql.com-20071223184258-15140
  - sp1r-brian@zim.(none)-20080206122216-35774
  - sp1r-baker@bk-internal.mysql.com-20080209005622-35947
  - sp1r-baker@bk-internal.mysql.com-20080224215608-24613
  - sp1r-baker@bk-internal.mysql.com-20080307170710-63543
  - sp1r-baker@bk-internal.mysql.com-20080312233205-13069
  - sp1r-Reggie@core.-20080402175211-28643
  - kpettersson@mysql.com-20080901101150-4ne74r8v0492vv42
  - alik@sun.com-20090805173811-9fzt0ymcp9tsvn7k
  - alik@sun.com-20090805173937-fcv1fdveodq5x9gb
  - alik@sun.com-20090805175009-g1od16i3t1xkw2qr
  - kostja@sun.com-20090805200643-j9i4fy7ii8ijho5c
  - alik@sun.com-20090807195303-j4fb5m4l1dgdahwo
  - alik@sun.com-20090808114848-3rkzr9kifrijzaqy
  - alik@sun.com-20090810041739-ugmx34h34uid8mox
  - alik@sun.com-20090810105306-rf43rfyzzblsy5e7
  - alik@sun.com-20090810123113-ccdjwai68b5woqdm
  - alik@sun.com-20090811080423-gb7pibec1znaydzy
  - alik@sun.com-20090811082130-5uckar1vx3kdsw7g
  - alik@sun.com-20090812202051-uqkfwwxxcjvo5ean

The following bugfixes are also backported within this patch:
  - Bug#34292: netdb.h missing in hostname.cc
  - Bug#39153: Failing to lookup a host name can lead to crash
    in current IPv6 implementation
  - Bug#38247: Server does not resolve connecting ip's
  - Bug#43006: main.skip_name_resolve fails on Windows in PB2
  - Bug#45606: ACL requires IPv4-mapped addresses to be used
  - Bug#45584: Host name cache does not work as a cache

------------------------------------------------------------
revno: 3559
committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
branch nick: mysql-pe
timestamp: Fri 2009-08-28 15:23:16 -0300
message:
Break down a large and obnoxious "if" statement. Multiple "if" statements
makes it easy to understand and follow the code (specially in a debugger).

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.

No commit message

----------------------------------------------------------------------
ChangeSet@1.2571, 2008-04-08 12:30:06+02:00, vvaintroub@wva. +122 -0
  Bug#32082 : definition of VOID in my_global.h conflicts with Windows
  SDK headers
  
  VOID macro is now removed. Its usage is replaced with void cast.
  In some cases, where cast does not make much sense (pthread_*, printf, 
  hash_delete, my_seek), cast is ommited.

-------------------------------------------------------------
revno: 2877
committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
branch nick: 35164-6.0
timestamp: Wed 2008-10-15 19:53:18 -0300
message:
Bug#35164: Large number of invalid pthread_attr_setschedparam calls
Bug#37536: Thread scheduling causes performance degradation at low thread count
Bug#12702: Long queries take 100% of CPU and freeze other applications under Windows

The problem is that although having threads with different priorities
yields marginal improvements [1] in some platforms [2], relying on some
statically defined priorities (QUERY_PRIOR and WAIT_PRIOR) to play well
(or to work at all) with different scheduling practices and disciplines
is, at best, a shot in the dark as the meaning of priority values may
change depending on the scheduling policy set for the process.

Another problem is that increasing priorities can hurt other concurrent
(running on the same hardware) applications (such as AMP) by causing
starvation problems as MySQL threads will successively preempt lower
priority processes. This can be evidenced by Bug#12702.

The solution is to not change the threads priorities and rely on the
system scheduler to perform its job. This also enables a system admin
to increase or decrease the scheduling priority of the MySQL process,
if intended.

Furthermore, the internal wrappers and code for changing the priority
of threads is being removed as they are now unused and ancient.

1. Due to unintentional side effects. On Solaris this could artificially
help benchmarks as calling the priority changing syscall millions of
times is more beneficial than the actual setting of the priority.

2. Where it actually works. It has never worked on Linux as the default
scheduling policy SCHED_OTHER only accepts the static priority 0.

------------------------------------------------------------
revno: 2630.13.2
committer: Davi Arnaut <davi@sun.com>
branch nick: WL4284-6.0
timestamp: Thu 2008-07-03 18:26:51 -0300
message:
Remove unused USING_TRANSACTIONS macro which unnecessarily
cumbers the code. This macro is a historical leftover and
has no practical use since its unconditionally defined.

------------------------------------------------------------
revno: 2642
committer: davi@mysql.com/endora.local
timestamp: Fri 2008-05-16 01:29:09 -0300
message:
Fix for a valgrind warning due to a jump on a uninitialized
variable. The problem was that the sql profile preparation
function wasn't being called for all possible code paths
of query execution. The solution is to move the preparation
to the dispatch_command function and to explicitly call the
profile preparation function on bootstrap.

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.

------------------------------------------------------------
revno: 2627
committer: davi@mysql.com/endora.local
timestamp: Wed 2008-04-23 13:25:02 -0300
message:
Fix for a build failure on Windows due to ssize_t
not being declared.

Original changeset:
------------------------------------------------------------
revno: 2626
committer: davi@mysql.com/endora.local
timestamp: Wed 2008-04-23 09:33:25 -0300
message:
Fix for main.ssl and main.ssl_compress test case failures under pool-of-threads.

The problem is that the SSL layer has a read buffer and might read
more data than requested by the VIO layer. The SSL layer empties the
socket buffer which causes the socket to not be signaled for IO if
the client is waiting for a command which is sitting in the read
buffer.

The solution is to retrieve from the transport layer the number of
bytes waiting in the read buffer. The data in the read buffer needs
to be processed before waiting for more data.

 inside a stored routine" from 6.0-codebase.

------------------------------------------------------------
revno: 2597.42.4
committer: davi@mysql.com/endora.local
timestamp: Tue 2008-04-15 17:29:42 -0300
message:
Bug#36004 mysql_stmt_prepare resets the list of warnings

Although the manual says that "the list of messages is reset
for each new statement that uses a table", the list of messages
is being unconditionally reset for prepare commands.

The solution is to enforce that the prepare command will only
reset the message list if the statement being prepared uses
a table or a warning is pushed.