sql/sql_base.cc:
  Query_arena *arena and backup are both unused.
  Removing those, allows us to remove select_lex->conds_processed_with_permanent_arena
sql/sql_lex.cc:
  conds_processed_with_permanent_arena is unused
sql/sql_lex.h:
  conds_processed_with_permanent_arena was unused

        ------------------------------------------------------------
        revno: 2617.81.1
        revision-id: tor.didriksen@sun.com-20090924061133-qo02zotz3yypmfpk
        parent: davi.arnaut@sun.com-20090923203724-tvz7x8dauzp686v7
        committer: Tor Didriksen <tor.didriksen@sun.com>
        branch nick: 6.0-codebase-bf-opt
        timestamp: Thu 2009-09-24 08:11:33 +0200
        message:
          Bug#47511 Segmentation fault during cleanup in sql_union (events_bugs.test)
          


sql/sql_lex.h:
  Ensure that fields used during cleanup() are always initialized by constructors.

since support for "%g" and "%f" has not been backported yet.

dbug/dbug.c:
  Use vsnprintf rather than my_vsnprintf.

The semisync plugin library names on Unix like systems were prefixed with
'lib', which did not follow the conventions.

Fix the problem by removing the 'lib' prefix on Unix systems.


mysql-test/mysql-test-run.pl:
  Remove 'lib' prefix for semisync plugin library names
plugin/semisync/Makefile.am:
  Remove 'lib' prefix for semisync plugin library names
plugin/semisync/plug.in:
  Remove 'lib' prefix for semisync plugin library names

Conflicts:
  - sql/sql_insert.cc

    the 'shared-memory-base-name' was added to the [client] section of the my.cnf file.
    That option isn't supported by the mysqltest_embedded.

per-file comments:
  mysql-test/lib/My/ConfigFactory.pm

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

sql/sql_base.cc:
  Break down a large and obnoxious "if" statement. Multiple "if" statements
  makes it easy to understand and follow the code (specially in a debugger).

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.


client/mysqladmin.cc:
  Bug#32082 : remove VOID macro
client/mysqldump.c:
  Bug#32082 : remove VOID macro
client/mysqlimport.c:
  Bug#32082 : remove VOID macro
client/mysqlslap.c:
  Bug#32082 : remove VOID macro
client/mysqltest.cc:
  Bug#32082 : remove VOID macro
client/sql_string.cc:
  Bug#32082 : remove VOID macro
extra/comp_err.c:
  Bug#32082 : remove VOID macro
extra/replace.c:
  Bug#32082 : remove VOID macro
include/my_alarm.h:
  Bug#32082 : remove VOID macro
include/my_global.h:
  Bug#32082 : remove VOID macro
libmysql/libmysql.c:
  Bug#32082 : remove VOID macro
mysys/errors.c:
  Bug#32082 : remove VOID macro
mysys/hash.c:
  Bug#32082 : remove VOID macro
mysys/mf_iocache2.c:
  Bug#32082 : remove VOID macro
mysys/mf_loadpath.c:
  Bug#32082 : remove VOID macro
mysys/mf_path.c:
  Bug#32082 : remove VOID macro
mysys/my_append.c:
  Bug#32082 : remove VOID macro
mysys/my_clock.c:
  Bug#32082 : remove VOID macro
mysys/my_copy.c:
  Bug#32082 : remove VOID macro
mysys/my_fstream.c:
  Bug#32082 : remove VOID macro
mysys/my_getwd.c:
  Bug#32082 : remove VOID macro
mysys/my_lib.c:
  Bug#32082 : remove VOID macro
mysys/my_lockmem.c:
  Bug#32082 : remove VOID macro
mysys/my_pthread.c:
  Bug#32082 : remove VOID macro
mysys/my_redel.c:
  Bug#32082 : remove VOID macro
mysys/stacktrace.c:
  Bug#32082 : remove VOID macro
mysys/thr_alarm.c:
  Bug#32082 : remove VOID macro
mysys/thr_lock.c:
  Bug#32082 : remove VOID macro
sql/derror.cc:
  Bug#32082 : remove VOID macro
sql/des_key_file.cc:
  Bug#32082 : remove VOID macro
sql/discover.cc:
  Bug#32082 : remove VOID macro
sql/field.cc:
  Bug#32082 : remove VOID macro
sql/filesort.cc:
  Bug#32082 : remove VOID macro
sql/ha_ndbcluster.cc:
  Bug#32082 : remove VOID macro
sql/ha_partition.cc:
  Bug#32082 : remove VOID macro
sql/handler.cc:
  Bug#32082 : remove VOID macro
sql/hostname.cc:
  Bug#32082 : remove VOID macro
sql/init.cc:
  Bug#32082 : remove VOID macro
sql/item.cc:
  Bug#32082 : remove VOID macro
sql/item_cmpfunc.cc:
  Bug#32082 : remove VOID macro
sql/item_strfunc.cc:
  Bug#32082 : remove VOID macro
sql/lock.cc:
  Bug#32082 : remove VOID macro
sql/log.cc:
  Bug#32082 : remove VOID macro
sql/log_event.cc:
  Bug#32082 : remove VOID macro
sql/mysqld.cc:
  Bug#32082 : remove VOID macro
sql/opt_range.h:
  Bug#32082 : remove VOID macro
sql/protocol.cc:
  Bug#32082 : remove VOID macro
sql/records.cc:
  Bug#32082 : remove VOID macro
sql/sp_head.cc:
  Bug#32082 : remove VOID macro
sql/sp_pcontext.cc:
  Bug#32082 : remove VOID macro
sql/sql_acl.cc:
  Bug#32082 : remove VOID macro
sql/sql_base.cc:
  Bug#32082 : remove VOID macro
sql/sql_cache.cc:
  Bug#32082 : remove VOID macro
sql/sql_connect.cc:
  Bug#32082 : remove VOID macro
sql/sql_db.cc:
  Bug#32082 : remove VOID macro
sql/sql_delete.cc:
  Bug#32082 : remove VOID macro
sql/sql_handler.cc:
  Bug#32082 : remove VOID macro
sql/sql_insert.cc:
  Bug#32082 : remove VOID macro
sql/sql_map.cc:
  Bug#32082 : remove VOID macro
sql/sql_parse.cc:
  Bug#32082 : remove VOID macro
sql/sql_select.cc:
  Bug#32082 : remove VOID macro
sql/sql_servers.cc:
  Bug#32082 : remove VOID macro
sql/sql_show.cc:
  Bug#32082 : remove VOID macro
sql/sql_string.cc:
  Bug#32082 : remove VOID macro
sql/sql_table.cc:
  Bug#32082 : remove VOID macro
sql/sql_test.cc:
  Bug#32082 : remove VOID macro
sql/sql_trigger.cc:
  Bug#32082 : remove VOID macro
sql/sql_update.cc:
  Bug#32082 : remove VOID macro
sql/sql_view.cc:
  Bug#32082 : remove VOID macro
sql/table.cc:
  Bug#32082 : remove VOID macro
sql/tztime.cc:
  Bug#32082 : remove VOID macro
sql/udf_example.c:
  Bug#32082 : remove VOID macro
sql/uniques.cc:
  Bug#32082 : remove VOID macro
sql/unireg.cc:
  Bug#32082 : remove VOID macro
storage/archive/ha_archive.cc:
  Bug#32082 : remove VOID macro
storage/blackhole/ha_blackhole.cc:
  Bug#32082 : remove VOID macro
storage/csv/ha_tina.cc:
  Bug#32082 : remove VOID macro
storage/csv/transparent_file.cc:
  Bug#32082 : remove VOID macro
storage/example/ha_example.cc:
  Bug#32082 : remove VOID macro
storage/federated/ha_federated.cc:
  Bug#32082 : remove VOID macro
storage/heap/hp_clear.c:
  Bug#32082 : remove VOID macro
storage/heap/hp_create.c:
  Bug#32082 : remove VOID macro
storage/heap/hp_test1.c:
  Bug#32082 : remove VOID macro
storage/heap/hp_test2.c:
  Bug#32082 : remove VOID macro
storage/innobase/handler/ha_innodb.cc:
  Bug#32082 : remove VOID macro
storage/myisam/ft_eval.c:
  Bug#32082 : remove VOID macro
storage/myisam/ha_myisam.cc:
  Bug#32082 : remove VOID macro
storage/myisam/mi_changed.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_check.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_close.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_create.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_dbug.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_delete.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_delete_all.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_dynrec.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_info.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_locking.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_log.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_open.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_packrec.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_panic.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_rsame.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_statrec.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_test1.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_test2.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_test3.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_update.c:
  Bug#32082 : remove VOID macro
storage/myisam/mi_write.c:
  Bug#32082 : remove VOID macro
storage/myisam/myisamchk.c:
  Bug#32082 : remove VOID macro
storage/myisam/myisamlog.c:
  Bug#32082 : remove VOID macro
storage/myisam/myisampack.c:
  Bug#32082 : remove VOID macro
storage/myisam/sort.c:
  Bug#32082 : remove VOID macro
storage/myisammrg/myrg_close.c:
  Bug#32082 : remove VOID macro
storage/myisammrg/myrg_create.c:
  Bug#32082 : remove VOID macro
storage/myisammrg/myrg_open.c:
  Bug#32082 : remove VOID macro
strings/str_test.c:
  Bug#32082 : remove VOID macro
tests/thread_test.c:
  Bug#32082 : remove VOID macro

mysql-test/r/log_tables.result:
  Bug #35765  	ALTER TABLE produces wrong error when non-existent storage engine used
  
  Updated result
mysql-test/r/partition.result:
  Bug #35765  	ALTER TABLE produces wrong error when non-existent storage engine used
  
  Updated result
mysql-test/r/partition_innodb.result:
  Bug #35765  	ALTER TABLE produces wrong error when non-existent storage engine used
  
  Updated result
mysql-test/t/log_tables.test:
  Bug #35765  	ALTER TABLE produces wrong error when non-existent storage engine used
  
  Updated test
mysql-test/t/partition.test:
  Bug #35765  	ALTER TABLE produces wrong error when non-existent storage engine used
  
  Added test case
mysql-test/t/partition_innodb.test:
  Bug #35765  	ALTER TABLE produces wrong error when non-existent storage engine used
  
  Updated test
sql/protocol.cc:
  Bug #35765  	ALTER TABLE produces wrong error when non-existent storage engine used
  
  (fix of bug#48939 to avoid test failures on my test build).
sql/sql_yacc.yy:
  Bug #35765  	ALTER TABLE produces wrong error when non-existent storage engine used
  
  if no existing engine was given, don't set HA_CREATE_USED_ENGINE

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


configure.in:
  Remove checks for functions that are not used anymore.
include/config-netware.h:
  Remove unused define.
include/my_pthread.h:
  Remove thread priority changing wrappers.
mysys/my_pthread.c:
  Remove thread priority changing wrappers. They do not work properly
  and their implementations were incorrectly protected by a check for
  HAVE_PTHREAD_SETSCHEDPARAM.
mysys/thr_alarm.c:
  Remove meaningless (100) increase of a thread priority.
sql/mysql_priv.h:
  Remove meaningless thread priority values.
sql/mysqld.cc:
  Don't change thread priorities.
sql/slave.cc:
  Don't change thread priorities.
sql/slave.h:
  Update function prototype.
sql/sql_parse.cc:
  Don't change thread priorities.
sql/sql_prepare.cc:
  Don't change thread priorities.
sql/unireg.h:
  Mark flag as obsolete.
storage/innobase/handler/ha_innodb.cc:
  Remove use of obsolete flag and associated behavior.
storage/innobase/include/srv0srv.h:
  Remove use of obsolete flag and associated variables.
storage/innobase/os/os0thread.c:
  Remove use of obsolete flag and associated behavior.
storage/innobase/srv/srv0srv.c:
  Remove use of obsolete flag and associated variables.

           root-directory not writable

Rather than use the -w test, attempt the chown and bail out if
it fails.

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


sql/handler.cc:
  Remove an always defined #ifdef (USING_TRNASACTIONS).
sql/handler.h:
  Remove an always defined #ifdef (USING_TRNASACTIONS).
sql/log.cc:
  Remove an always defined #ifdef (USING_TRNASACTIONS).
sql/log_event.cc:
  Remove an always defined #ifdef (USING_TRNASACTIONS).
sql/set_var.cc:
  Remove an always defined #ifdef (USING_TRNASACTIONS).
sql/sql_class.cc:
  Remove an always defined #ifdef (USING_TRNASACTIONS).
sql/sql_class.h:
  Remove an always defined #ifdef (USING_TRNASACTIONS).
sql/sql_parse.cc:
  Remove an always defined #ifdef (USING_TRNASACTIONS).

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

left join 

When creating a temporary TEXT/BLOB field from an Item in
Item::make_string_field(), the field's type was unconditionally
set to the one corresponding to the maximum length (i.e.
LONGTEXT/ LONGBLOB). This resulted in problems when exactly the
same TEXT/BLOB is type required in cases like CREATE ... SELECT
or creating internal temporary tables for joins. 

Fixed by calling a different constructor for Field_blob so that
an appropriate type is used depending on the Item's max_length
value.

Updated the result file for func_math.

sql/sql_table.cc:
  Add the missing return 0

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

This is the non-ndb part of the patch.

The return value of mysql_bin_log.write was ignored by most callers,
which may lead to inconsistent on master and slave if the transaction
was committed while the binlog was not correctly written. If
my_error() is call in mysql_bin_log.write, this could also lead to
assertion issue if my_ok() or my_error() is called after.

This fixed the problem by let the caller to check and handle the
return value of mysql_bin_log.write. This patch only adresses the
simple cases.


mysql-test/include/binlog_inject_error.inc:
  inject binlog write error when doing a query
mysql-test/suite/binlog/t/binlog_write_error.test:
  Simple test case to check if proper error is reported when injecting binlog write errors.
sql/events.cc:
  check return value of mysql_bin_log.write
sql/log.cc:
  check return value of mysql_bin_log.write
sql/log_event.cc:
  check return value of mysql_bin_log.write
sql/log_event_old.cc:
  check return value of mysql_bin_log.write
sql/mysql_priv.h:
  Change write_bin_log to return int instead of void
sql/rpl_injector.cc:
  check return value of writing binlog
sql/sp.cc:
  check return value of writing binlog
sql/sp_head.cc:
  return 1 if writing binlog failed
sql/sql_acl.cc:
  check return value of writing binlog
sql/sql_base.cc:
  check return value of writing binlog
sql/sql_class.h:
  Change binlog_show_create_table to return int
sql/sql_db.cc:
  Change write_to_binlog to return int
  check return value of writing binlog
sql/sql_delete.cc:
  check return value of writing binlog
sql/sql_insert.cc:
  check return value of writing binlog
sql/sql_load.cc:
  check return value of writing binlog
sql/sql_parse.cc:
  check return value of writing binlog
sql/sql_partition.cc:
  check return value of writing binlog
sql/sql_rename.cc:
  check return value of writing binlog
sql/sql_repl.cc:
  check return value of writing binlog
sql/sql_table.cc:
  Change write_bin_log to return int, and return 1 if there was error writing binlog
sql/sql_tablespace.cc:
  check return value of writing binlog
sql/sql_trigger.cc:
  check return value of writing binlog
sql/sql_udf.cc:
  check return value of writing binlog
sql/sql_update.cc:
  check return value of writing binlog
sql/sql_view.cc:
  check return value of writing binlog

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.


tests/mysql_client_test.c:
  Add test case for Bug#36004

mysql-test/t/sp-error.test:
  Backport test of Bug#36510 (the bug itself is fixed by other
  backports, inc. SINGAL code).

------------------------------------------------------------
revno: 2572.23.1
committer: davi@mysql.com/endora.local
timestamp: Wed 2008-03-19 09:03:08 -0300
message:
Bug#17954 Threads_connected > Threads_created

The problem is that insert delayed threads are counted as connected
but not as created, leading to a Threads_connected value greater then
the Threads_created value.

The solution is to enforce the documented behavior that the
Threads_connected value shall be the number of currently
open connections and that Threads_created shall be the
number of threads created to handle connections.


mysql-test/r/status.result:
  Add test case result for Bug#17954
mysql-test/t/status.test:
  Add test case for Bug#17954
sql/mysqld.cc:
  Change Threads_connected to reflect the number of
  open connections. SHOW_INT type variables are not
  reset.

------------------------------------------------------------
revno: 2476.1116.1
committer: davi@mysql.com/endora.local
timestamp: Fri 2007-12-14 10:10:19 -0200
message:
DROP TABLE under LOCK TABLES simultaneous to a FLUSH TABLES
WITH READ LOCK (global read lock) can lead to a deadlock.

The solution is to not wait for the global read lock if the
thread is holding any locked tables.

Related to bugs 23713 and 32395. This issues is being fixed
only on 6.0 because it depends on the fix for bug 25858 --
which was fixed only on 6.0.