Several items said to be deprecated in the 4.1 manual
have never been removed. This worklog adds deprecation
warnings when these items are used, and warns the user
that the items will be removed in MySQL 5.6.
A couple of previously deprecation decision have been
reversed (see single file comments)
"mysql_upgrade (ver 5.1) add 3 fields to mysql.proc table but does
not set values".
mysql_upgrade (ver 5.1) adds 3 fields (character_set_client,
collation_connection and db_collation) to the mysql.proc table, but
does not set any values. When we run stored procedures, which were
created with mysql 5.0, a warning is logged into the error log.
The solution to this is for mysql_upgrade to set default best guess
values for these fields. A warning is also written during upgrade, to
make the user aware that default values are set.
special chars
This script failed when the user tried passwords with multiple spaces, \, # or
' characters. Now proper escaping and quoting is used in all contexts.
This problem occurs in the Perl version of this script, too, so fix it in both
places.
Term::ReadKey"
Add the missing module import. Also, while here, fix a few glaring problems
with the script, and ensure that it behaves properly. It seems this script
may have never been working correctly (e.g., reading password didn't chomp()
the result, so password was set with \n at the end; comparing the re-typed
password to original was done with inverted test).
Add END { cleanup(); } block to ensure the script removes temporary working
files.
Add SIG{INT} / SIG{QUIT} handler.
Do a bit of reorganization to make the code easier to understand.
Limit failed connection attempts to 3.
Use ./bin/mysql if it exists, and then fall back on mysql in PATH (before it
assumed 'mysql' in the path). Print a nicer error if 'mysql' can't be called.
This has been tested on Windows (ActivePerl from cmd.exe, no cygwin needed)
and Linux.
Problem 1:
column_priv_hash uses utf8_general_ci collation
for the key comparison. The key consists of user name,
db name and table name. Thus user with privileges on table t1
is able to perform the same operation on T1
(the similar situation with user name & db name, see acl_cache).
So collation which is used for column_priv_hash and acl_cache
should be case sensitive.
The fix:
replace system_charset_info with my_charset_utf8_bin for
column_priv_hash and acl_cache
Problem 2:
The same situation with proc_priv_hash, func_priv_hash,
the only difference is that Routine name is case insensitive.
So the fix is to use my_charset_utf8_bin for
proc_priv_hash & func_priv_hash and convert routine name into lower
case before writing the element into the hash and
before looking up the key.
Additional fix: mysql.procs_priv Routine_name field collation
is changed to utf8_general_ci.
It's necessary for REVOKE command
(to find a field by routine hash element values).
Note:
It's safe for lower-case-table-names mode too because
db name & table name are converted into lower case
(see GRANT_NAME::GRANT_NAME).
"make_binary_distribution" does not always generate correct names
Originally, we solved deficiencies of the predefined "autoconf" macros
(at least on OS X 10.5, they do not correctly differ between "x86" and
"x86_64") by providing explicit "--platform" arguments.
With this patch, "make_binary_distribution" evaluates CFLAGS, so it
"just works" because CFLAGS contains information about the target CPU.
This patch is accompanied by a change in our build tools that drops the
setting of "--platform" arguments.
occasionally.
mysql_multi can call mysqld_safe. In doing this it's not changing the
current working directory. This may cause confusion in the case where
mysqld_multi is handling instances of servers of different versions
and the current working directory is the installation directory of one
of these servers.
Fixed by enhancing the meaning of basedir in [mysqldN] sections of
mysqld_multi. If specified, mysqld_multi will change the current
working directory to the basedir directory before starting the server
in mysqld_multi ... start ... and then change it back to what it was.
doesn't find 'logger'
Due to a variable quoting mistake, the $PATH environment
variable isn't parsed correctly when searching for the
existence of the desired executable(s) (logger in this
case).
This patch removes the quotes.
165 changesets with 23 conflicts:
Text conflict in mysql-test/r/lock_multi.result
Text conflict in mysql-test/t/lock_multi.test
Text conflict in mysql-test/t/mysqldump.test
Text conflict in sql/item_strfunc.cc
Text conflict in sql/log.cc
Text conflict in sql/log_event.cc
Text conflict in sql/parse_file.cc
Text conflict in sql/slave.cc
Text conflict in sql/sp.cc
Text conflict in sql/sp_head.cc
Text conflict in sql/sql_acl.cc
Text conflict in sql/sql_base.cc
Text conflict in sql/sql_class.cc
Text conflict in sql/sql_crypt.cc
Text conflict in sql/sql_db.cc
Text conflict in sql/sql_lex.cc
Text conflict in sql/sql_parse.cc
Text conflict in sql/sql_select.cc
Text conflict in sql/sql_table.cc
Text conflict in sql/sql_view.cc
Text conflict in storage/innobase/handler/ha_innodb.cc
Text conflict in storage/myisam/mi_packrec.c
Text conflict in tests/mysql_client_test.c
Updates to Innobase, taken from main 5.1:
bzr: ERROR: Some change isn't sane:
File mysql-test/r/innodb-semi-consistent.result is owned by Innobase and should not be updated.
File mysql-test/t/innodb-semi-consistent.test is owned by Innobase and should not be updated.
File storage/innobase/handler/ha_innodb.cc is owned by Innobase and should not be updated.
File storage/innobase/ibuf/ibuf0ibuf.c is owned by Innobase and should not be updated.
File storage/innobase/include/row0mysql.h is owned by Innobase and should not be updated.
File storage/innobase/include/srv0srv.h is owned by Innobase and should not be updated.
File storage/innobase/include/trx0trx.h is owned by Innobase and should not be updated.
File storage/innobase/include/trx0trx.ic is owned by Innobase and should not be updated.
File storage/innobase/lock/lock0lock.c is owned by Innobase and should not be updated.
File storage/innobase/page/page0cur.c is owned by Innobase and should not be updated.
File storage/innobase/row/row0mysql.c is owned by Innobase and should not be updated.
File storage/innobase/row/row0sel.c is owned by Innobase and should not be updated.
File storage/innobase/srv/srv0srv.c is owned by Innobase and should not be updated.
File storage/innobase/trx/trx0trx.c is owned by Innobase and should not be updated.
(Set env var 'ALLOW_UPDATE_INNOBASE_OWNED' to override.)
preventing a change that would result in table data loss. (Bug #27149)
Also updated mysql_convert_table_format to use --engine as the documentation
claimed, and use the engine terminology throughout instead of the obsolete
'table type'.
Bug#32136: mysqld_multi --defaults-file not respected while using \
--mysqld=mysqld_safe
Revert change that adds "--no-defaults" to mysqld_multi.
This closes Bug#43508 and re-opens Bug#32136.
The problem is that creating a event could fail if the value of
the variable server_id didn't fit in the originator column of
the event system table. The cause is two-fold: it was possible
to set server_id to a value outside the documented range (from
0 to 2^32-1) and the originator column of the event table didn't
have enough room for values in this range.
The log tables (general_log and slow_log) also don't have a proper
column type to store the server_id and having a large server_id
value could prevent queries from being logged.
The solution is to ensure that all system tables that store the
server_id value have a proper column type (int unsigned) and that
the variable can't be set to a value that is not within the range.
Options got normalised to long rather than short options
since we gave primary name and alias in wrong order.
Consequently querying for the option using the short
options (the correct primary name) didn't work, rendering
the options in question inaccessible.
We restore the right order of the universe, or at least
the alii for --debug and --verbose.
