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.

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

      
When the data directory contained a symbolic link to another
file system, and the DATA or INDEX DIRECTORY clause of a
CREATE TABLE statement referred to a subdirectory of the data
directory, this was accepted.
      
The problem was the use of a table file path name, which included
the table name without an extension, for the comparison against
the data directory path name. This was almost always a
non-existent file. The internal algorithm failed to resolve
symbolic links for non-existent files. So we compared unrelated
path names.
      
Fixed by truncating the table name from the path before resolving
symlinks. If this is also a non-existent path, the creation of
the table will fail anyway.

Backport to 5.6.0.    6.0-codebase revid: 2599.60.1

                      .frm file
      
Added FLUSH TABLES before myisampack --join operation to fix the test 
warnings or errors
Removed unused variable in create_dest_frm() method

table .frm file
            
Problem:
========
Myisampack --join did not create the destination table .frm file. 
The user had to copy one of the source table .frm file as destination .frm 
file for mysql server to recognize. This is just 'user-friendliness' issue.
            
How it was solved
=================
After successful join and compression we copy the frm file from the first 
source table.
            
Functionality added
===================
myisampack --join=/path/t3 /path/t1 /path/t2 creates 
/path/t3.frm (which is bascially copied from first table's frm /path/t1)
      
Tests
=====
Modified myisampack.test to test two scenario's
1. Positive myisampack --join test
   In this case after the join operation is done,we test if the destination 
   table is accessible from the server
2. Positive myisampack --join test with an existing .frm file.
   We test the above case with an existing .frm file for the destination 
   table. It should return success even in this case.
3. Positive myisampack --join test with no .frm file for source tables
   We test the join operation with no .frm files for source tables. It should
   complete the join operation without any warnings and error messages
4. Negative myisampack --join test
   We test myisampack --join with existing .MYI,.MDI,.frm files for the 
   destination table. It should fail with exit status 2 in this case.

branch due to BUG#46853
      
Commented out the testcase for Bug#45816 in mysql-pe branch
due to valgrind warnings. Please see Bug#46853

Select queries on archive tables when joined on their primary keys
returns no results(empty set)
      
Archive storage doesn't inform the handler about the fetched record 
status when it is found. Fixed the archive storage engine to update
the record status when it fetches successfully

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.