This does not bring any contents changes, it is purely
metadata which are affected.
Details:
Even within 5.0, most of these changesets did not cause
file contents changes, because they were backports done
for the "service pack" builds of 5.0.66sp1 and 5.0.72sp1.
The "real" changesets are also already present in 5.1,
so this upmerge doesn't change any contents.
The only "real" changeset in 5.0 was a fix of the shell
scripts used to configure bdb (BerkeleyDB).
As we completele removed bdb from the 5.1 sources already,
the affected files are not present in the 5.1 source tree,
so this changeset also does not cause any contents changes.
Post-fix test failure: fixed mysqlcheck.test on Windows platforms.
mysql-test/r/mysqlcheck.result:
fixed mysqlcheck.test on Windows platforms.
mysql-test/t/mysqlcheck.test:
fixed mysqlcheck.test on Windows platforms.
bug#33094: Error in upgrading from 5.0 to 5.1 when table contains
triggers
and
#41385: Crash when attempting to repair a #mysql50# upgraded table
with triggers.
Problem:
1. trigger code didn't assume a table name may have
a "#mysql50#" prefix, that may lead to a failing ASSERT().
2. "ALTER DATABASE ... UPGRADE DATA DIRECTORY NAME" failed
for databases with "#mysql50#" prefix if any trigger.
3. mysqlcheck --fix-table-name didn't use UTF8 as a default
character set that resulted in (parsing) errors for tables with
non-latin symbols in their names and definitions of triggers.
Fix:
1. properly handle table/database names with "#mysql50#" prefix.
2. handle --default-character-set mysqlcheck option;
if mysqlcheck is launched with --fix-table-name or --fix-db-name
set default character set to UTF8 if no --default-character-set
option given.
Note: if given --fix-table-name or --fix-db-name option,
without --default-character-set mysqlcheck option
default character set is UTF8.
client/mysqlcheck.c:
Fix for
bug#33094: Error in upgrading from 5.0 to 5.1 when table contains
triggers
and
#41385: Crash when attempting to repair a #mysql50# upgraded table
with triggers.
- check and set default charset if --default-character-set option
given.
- set default charset to "utf8" if there's
--fix-table-name or --fix-db-name and no --default-character-set.
mysql-test/r/mysqlcheck.result:
Fix for
bug#33094: Error in upgrading from 5.0 to 5.1 when table contains
triggers
and
#41385: Crash when attempting to repair a #mysql50# upgraded table
with triggers.
- test result.
mysql-test/t/mysqlcheck.test:
Fix for
bug#33094: Error in upgrading from 5.0 to 5.1 when table contains
triggers
and
#41385: Crash when attempting to repair a #mysql50# upgraded table
with triggers.
- test case.
sql/mysql_priv.h:
Fix for
bug#33094: Error in upgrading from 5.0 to 5.1 when table contains
triggers
and
#41385: Crash when attempting to repair a #mysql50# upgraded table
with triggers.
- check_n_cut_mysql50_prefix() introduced.
sql/sql_table.cc:
Fix for
bug#33094: Error in upgrading from 5.0 to 5.1 when table contains
triggers
and
#41385: Crash when attempting to repair a #mysql50# upgraded table
with triggers.
- tablename_to_filename() code split into 2 parts
- check_n_cut_mysql50_prefix() introduced to cut #mysql50# prefixes,
used in the trigger code as well.
sql/sql_trigger.cc:
Fix for
bug#33094: Error in upgrading from 5.0 to 5.1 when table contains
triggers
and
#41385: Crash when attempting to repair a #mysql50# upgraded table
with triggers.
- Table_triggers_list::check_n_load() - checking triggers assume
a table/database name given may have "#mysql50#" prefix in some cases.
- Table_triggers_list::change_table_name_in_triggers() -
create .TRG file in new database directory and delete it in old one,
as they may differ in case of
"ALTER DATABASE ... UPGRADE DATA DIRECTORY NAME"
- Table_triggers_list::change_table_name_in_trignames() - remove stale .TRN
files in #mysql50#dbname directory in case of database upgrade
- Table_triggers_list::change_table_name() - allow changing trigger's
database in case of its upgrading
sql/sql_trigger.h:
Fix for
bug#33094: Error in upgrading from 5.0 to 5.1 when table contains
triggers
and
#41385: Crash when attempting to repair a #mysql50# upgraded table
with triggers.
- new old_db_name parameter added in
Table_triggers_list::change_table_name_in_trignames() and
Table_triggers_list::change_table_name_in_triggers()
The next number (AUTO_INCREMENT) field of the table for write
rows events are not initialized, and cause some engines (innodb)
not correctly update the tables's auto_increment value.
This patch fixed this problem by honor next number fields if present.
mysql-test/extra/rpl_tests/rpl_auto_increment.test:
Add test code for BUG#41986
mysql-test/suite/rpl/r/rpl_auto_increment.result:
update test result file for BUG#41986
sql/log_event.cc:
set next_number_field before writing rows, and reset next_number_field after finished writing rows
The default "awk" there cannot handle some of the scripts
which are used by BDB for configuration.
The fix:
1) Introduce a variable "AWK" in some of the BDB shell scripts,
2) search "gawk" and give it precedence over "awk"
when assigning a value to the "AWK" variable,
fail if neither is found,
3) use that variable when calling an "awk" program with one
of the critical scripts.
The perfect solution would be to use the "awk" program found
by "configure", but we cannot follow that approach because
BDB's configuration is handled as a special case before the
overall "configure" is run. Because of this,
1) the "configure" result isn't yet available,
2) "configure" will not handle these BDB files.
Searching "gawk" is a (not-so-nice) way out.
Note that all this need not be perfectly portable,
it is needed only when we create a source distribution tarball
from a develkopment tree.
bdb/dist/s_all:
Search "gawk" if available, give it precedence over "awk",
fail if neither is found.
bdb/dist/s_include:
Ensure we use a modern AWK, similar to GNU awk,
the default awk on Solaris cannot handle BDB's script.
bdb/dist/s_recover:
Ensure we use a modern AWK, similar to GNU awk,
the default awk on Solaris cannot handle BDB's script.
bdb/dist/s_rpc:
Ensure we use a modern AWK, similar to GNU awk,
the default awk on Solaris cannot handle BDB's script.
+ add workaround for bug 38124
+ messages into the protocol when sessions are switched
+ replace error numbers by error names
+ reset of system variables to initial values per subtest
+ remove a file created by this test
+ minor improvements in structure and formatting
Added cleanup of status variables to the end of binlog_database.
Re-recorded .result file to account for cleanup statement.
NOTE: binlog.binlog_innodb also has had an FLUSH STATUS; statement added to it as well, but
adding this cleanup as a preventative measure.
Bug#36428: MY_MUTEX_INIT_FAST is used before initialization
On some thread implementations, we need a fake mutex attri-
bute as a placeholder, which we define as a global variable,
"my_fast_mutexattr". Well. that must be initialized before
used in any mutexes, and the ordering of initializations in
the API function my_init() was wrong.
Now, put my_thread_global_init(), which initializes the attri-
butes that mutexes require.
Bug #39920: MySQL cannot deal with Leap Second expression in string literal.
Updated MySQL time handling code to react correctly on UTC leap second additions.
MySQL functions that return the OS current time, like e.g. CURDATE(), NOW() etc
will return :59:59 instead of :59:60 or 59:61.
As a result the reader will receive :59:59 for 2 or 3 consecutive seconds
during the leap second.
Original changesets:
> revision-id: kgeorge@mysql.com-20081201141835-rg8nnnadujj5wl9f
> parent: gshchepa@mysql.com-20081114172557-xh0jlzwal8ze3cy6
> committer: Georgi Kodinov <kgeorge@mysql.com>
> branch nick: B39920-5.0-bugteam
> timestamp: Mon 2008-12-01 16:18:35 +0200
> revision-id: kgeorge@mysql.com-20081201154106-c310zzy5or043rqa
> parent: kgeorge@mysql.com-20081201145656-6kjq91oga5nxbbob
> committer: Georgi Kodinov <kgeorge@mysql.com>
> branch nick: B39920-merge-5.0-bugteam
> timestamp: Mon 2008-12-01 17:41:06 +0200
Bug#34760 Character set autodetection appears to fail
the problem is the same as reported in bug#20835,
so the fix is backport of bug#20835 patch.
Original changeset:
> revision-id: sergey.glukhov@sun.com-20081121123959-58ffhp2nitg7f40h
> parent: ramil@mysql.com-20081120100836-gct60cm67b1rui29
> committer: Sergey Glukhov <Sergey.Glukhov@sun.com>
> branch nick: mysql-5.0-bugteam
> timestamp: Fri 2008-11-21 16:39:59 +0400
Bounds-checks and blocksize corrections were applied to user-input,
but constants in the server were trusted implicitly. If these values
did not actually meet the requirements, the user could not set change
a variable, then set it back to the (wonky) factory default or maximum
by explicitly specifying it (SET <var>=<value> vs SET <var>=DEFAULT).
Now checks also apply to the server's presets. Wonky values and maxima
get corrected at startup. Consequently all non-offsetted values the user
sees are valid, and users can set the variable to that exact value if
they so desire.
mysql-test/r/read_buffer_size_basic.result:
test sets out of bounds value; we now throw a warning for this.
This is a side-effect: before, the maximum was higher than the
value we set here. The value was corrected to block-size, the
maximum was not, hence the value was smaller than the maximum
in this particular case. Now that we align the maxima at startup,
the value in SET is larger than the (corrected) maximum, and we
see a warning in this particular case. "This means we're doing it right."
mysql-test/r/read_rnd_buffer_size_basic.result:
test sets out of bounds value; we now throw a warning for this.
This is a side-effect: before, the maximum was higher than the
value we set here. The value was corrected to block-size, the
maximum was not, hence the value was smaller than the maximum
in this particular case. Now that we align the maxima at startup,
the value in SET is larger than the (corrected) maximum, and we
see a warning in this particular case. "This means we're doing it right."
mysys/my_getopt.c:
Do bounds-checking at start-up time so we'll catch and correct
wonky default values and upper limits.
sql/mysqld.cc:
If 0 is a legal value per the docs, not to mention the default, we shouldn't give 1 as
the lower limit.
storage/innobase/handler/ha_innodb.cc:
We are setting upper bounds here.
~0L gives -1. That is NOT what we want!
2. Avoid bad effects of bug 41925 Warning 1366 Incorrect string value:
... for column processlist.info
3. Add poll routines which ensure that subtests meet stable scenarios.
This does not change the sense of the subtests.
post push fix, added test found a valgrind warning
sql/sql_partition.cc:
Bug#40972: Partition pruning can lead to crash for bad dates
Fix for valgrind warning
Adding comments to some of the high-level functions in replication.
sql/log_event.h:
Fixed some mistakes in comments.
sql/repl_failsafe.cc:
Added comment for show_slave_hosts()
sql/slave.cc:
Added comment for show_master_info(), handle_slave_[sql|io](), and next_event()
sql/sql_binlog.cc:
Added @param comment.
sql/sql_lex.h:
Added comment for st_lex_master_info.
sql/sql_repl.cc:
Added comments for functions executing a statement:
PURGE BINARY LOGS
START SLAVE
STOP SLAVE
RESET SLAVE
CHANGE MASTER
RESET MASTER
SHOW BINLOG EVENTS
SHOW MASTER STATUS
SHOW BINARY LOGS
No need to mask the error code returned by getting the next row to end of file when
doing filesort.
mysql-test/r/innodb_mysql_rbk.result:
Bug #41543: test case
mysql-test/t/innodb_mysql_rbk-master.opt:
Bug #41543: test case
mysql-test/t/innodb_mysql_rbk.test:
Bug #41543: test case
sql/filesort.cc:
Bug #41543: No need to mask the error code returned by getting the next row to end of file when
doing filesort.
