Problem: The test case failed because: (i) warning text in
result file differed from the warning output by the
server, and (ii) binlog contents in result file did
not show the statements logged wrapped in BEGIN/COMMIT
as it is the case after WL 2687.
Solution: We update the result file, but first we change the
unsafe warning text to also refer to performance_schema
table(s). This required changing the result files for
existing test cases that provide output for warnings
related to ER_BINLOG_UNSAFE_SYSTEM_TABLE. "Grepping" in
result files, shows that only binlog_unsafe contained
reference to such a warning.
We also update the result file with the missing
BEGIN/COMMIT statements.
When starting mysqld it did not recognize most of the options given on
the command line when it was compiled for 32-bit Solaris using Sun
Studio compiler. The cause for this was that most of the entries in
the my_long_options array contained "garbage" data. The garbage data
was caused by a compiler bug. When initilizing the def_value member
for the "default-storage-engine" entry it was initialized like this:
(longlong)"MyISAM"
i.e. casting a 32 bit pointer to a 64 bit integer value. Due to the
compiler bug only 4 bytes was allocated (instead of 8 bytes). This
caused everything following this entry to be stored at a location that
was 4 byte wrong.
The fix/work-around for this problem is initialize the def_value
for default-storage-engine in my_long_options to 0 and instead
initialize the default_storage_engine variable to "MyISAM" in
init_common_variables().
sql/mysqld.cc:
Due to a bug in Sun Studio compiler when generating 32 bit code the
initialization of the def_value member of the default-storage-engine entry
in my_long_options only got 4 bytes allocated instead of 8 bytes.
The compiler bug was triggered by casting a 32 bit pointer to a 64 bit
integer value in the initialization code for my_long_options. To avoid
triggering the compiler bug the intialization of the def_value in
my_long_options is set to 0 and instead the default_storage_engine
is initialized to "MyISAM" in init_common_variables().
replicating
Replace c_ptr() calls with c_ptr_safe() calls to
avoid valgrind warnings.
Adding code to to handle the case that no metadata
was present in the table map for the column.
Allow first parameter to unpack_row() to be NULL,
in which case no source tables is used and hence
no checks nor conversions are done.
Clarifying some comments and fixing documentation
for unpack_row().
- mysqld--help-win
Updated result so that it contains missing
value for slave-type-conversions
- rpl_idempotency
This seems a bad merge. In BUG#39934, the contents of
this file had been split into rpl_row_idempontency and
rpl_idempotency. The patch was pushed to 5.1-rep+3 which
was later merged in rep+2-delivery1 which in turn was
merged in 5.1-rpl-merge. Now while merging next-mr in
5.1-rpl-merge, the file got back it's old content (which
is in rpl_row_idempotency now because of BUG#39934). This
cset reverts the bad merge:
bzr merge -r revid:dao-gang.qu@sun.com-20100112120709-ioxp11yl9bvquaqd..\
before:revid:dao-gang.qu@sun.com-20100112120709-ioxp11yl9bvquaqd\
suite/rpl/t/rpl_idempotency.test
- sys_vars.all_vars:
Added test case for slave_type_conversions variable
- rpl_row_idempotency
Removed ER_SLAVE_AMBIGOUS_EXEC_MODE (which was removed by WL 4738)
from the test case. Using ER_WRONG_VALUE_FOR_VAR instead.
- mysqld--help-win
Added missing help for --slave-type-conversions from the
result file.
Original revision:
------------------------------------------------------------
revno: 3817
revision-id: guilhem@mysql.com-20100108092756-k0zzf4kvx9b7bh38
parent: guilhem@mysql.com-20100107101133-hrrgcdqg508runuf
committer: Guilhem Bichot <guilhem@mysql.com>
branch nick: mysql-6.0-codebase-bugfixing
timestamp: Fri 2010-01-08 10:27:56 +0100
message:
fix for BUG#50120 "Valgrind errors in any test, inside mysqltest"
Problem was that as v->name[v->name_len] may be uninitialized (which is ok per se),
it shouldn't be used in an if(). We remove this zero_the_char/restore_it logic by
rather zero-terminating the v->name string when we create it in var_init().
------------------------------------------------------------
The test case did not start with fresh binlogs, so in some
cases, dependending on the order MTR runs the tests, it would
try to show binlog contents from invalid positions (binary log
would contain unexpected events from previous test).
We fix this by deploying a RESET MASTER at the beginning of the
test case.
Conflicts:
Text conflict in .bzr-mysql/default.conf
Text conflict in mysql-test/extra/rpl_tests/rpl_loaddata.test
Text conflict in mysql-test/r/mysqlbinlog2.result
Text conflict in mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result
Text conflict in mysql-test/suite/binlog/r/binlog_unsafe.result
Text conflict in mysql-test/suite/rpl/r/rpl_insert_id.result
Text conflict in mysql-test/suite/rpl/r/rpl_loaddata.result
Text conflict in mysql-test/suite/rpl/r/rpl_stm_auto_increment_bug33029.result
Text conflict in mysql-test/suite/rpl/r/rpl_udf.result
Text conflict in mysql-test/suite/rpl/t/rpl_slow_query_log.test
Text conflict in sql/field.h
Text conflict in sql/log.cc
Text conflict in sql/log_event.cc
Text conflict in sql/log_event_old.cc
Text conflict in sql/mysql_priv.h
Text conflict in sql/share/errmsg.txt
Text conflict in sql/sp.cc
Text conflict in sql/sql_acl.cc
Text conflict in sql/sql_base.cc
Text conflict in sql/sql_class.h
Text conflict in sql/sql_db.cc
Text conflict in sql/sql_delete.cc
Text conflict in sql/sql_insert.cc
Text conflict in sql/sql_lex.cc
Text conflict in sql/sql_lex.h
Text conflict in sql/sql_load.cc
Text conflict in sql/sql_table.cc
Text conflict in sql/sql_update.cc
Text conflict in sql/sql_view.cc
Conflict adding files to storage/innobase. Created directory.
Conflict because storage/innobase is not versioned, but has versioned children. Versioned directory.
Conflict adding file storage/innobase. Moved existing file to storage/innobase.moved.
Conflict adding files to storage/innobase/handler. Created directory.
Conflict because storage/innobase/handler is not versioned, but has versioned children. Versioned directory.
Contents conflict in storage/innobase/handler/ha_innodb.cc
WL#5151 was pushed.
Problem 1: Some old binlog events do not contain metadata. This
makes checking whether the field can be converted or not rather
impossible because one cannot compare, for instance, field sizes
from original table and target table.
Solution 1: When an event does not contain metadata, we will just
check if field types are equal and assume that original field
definition matched with the one in the target table.
Problem 2: There is a second fix, which involves lack of
information regarding maybe_null. This was causing a conditional
jump warning when creating a conversion table.
Solution 2: We will just assume that all fields that need to be
in the conversion table may be null.
mysql-test/r/index_merge_myisam.result:
@@optimizer_switch has a new flag
mysql-test/r/mysqld--help-notwin.result:
@@optimizer_switch has a new flag
mysql-test/r/mysqld--help-win.result:
@@optimizer_switch has a new flag
mysql-test/r/optimizer_switch_eng_cond_pushdown1.result:
Check how --engine-condition-pushdown and --optimizer-switch influence each other when used together (last wins).
mysql-test/r/optimizer_switch_eng_cond_pushdown2.result:
Check how --engine-condition-pushdown and --optimizer-switch influence each other when used together (last wins).
mysql-test/suite/ndb/r/ndb_condition_pushdown.result:
@@engine_condition_pushdown is deprecated, use @@optimizer_switch instead
mysql-test/suite/ndb/r/ndb_gis.result:
@@engine_condition_pushdown is deprecated, use @@optimizer_switch instead
mysql-test/suite/ndb/r/ndb_index_unique.result:
@@engine_condition_pushdown is deprecated, use @@optimizer_switch instead
mysql-test/suite/ndb/t/ndb_condition_pushdown.test:
@@engine_condition_pushdown is deprecated, use @@optimizer_switch instead
mysql-test/suite/ndb/t/ndb_gis.test:
@@engine_condition_pushdown is deprecated, use @@optimizer_switch instead
mysql-test/suite/ndb/t/ndb_index_unique.test:
@@engine_condition_pushdown is deprecated, use @@optimizer_switch instead
mysql-test/suite/sys_vars/r/engine_condition_pushdown_basic.result:
Setting @@engine_condition_pushdown gives a deprecation warning now.
We test that the engine_condition_pushdown flag of @@optimizer_switch, and @@engine_condition_pushdown
influence each other (turning the flag on/off sets the variable on/off and vice-versa).
mysql-test/suite/sys_vars/r/optimizer_switch_basic.result:
@@optimizer_switch has a new flag
mysql-test/suite/sys_vars/t/engine_condition_pushdown_basic.test:
Setting @@engine_condition_pushdown gives a deprecation warning now.
We test that the engine_condition_pushdown flag of @@optimizer_switch, and @@engine_condition_pushdown
influence each other (turning the flag on/off sets the variable on/off and vice-versa).
mysql-test/t/optimizer_switch_eng_cond_pushdown1-master.opt:
Check how --engine-condition-pushdown and --optimizer-switch influence each other when used together (last wins).
mysql-test/t/optimizer_switch_eng_cond_pushdown1.test:
Check how --engine-condition-pushdown and --optimizer-switch influence each other when used together (last wins).
mysql-test/t/optimizer_switch_eng_cond_pushdown2-master.opt:
Check how --engine-condition-pushdown and --optimizer-switch influence each other when used together (last wins).
mysql-test/t/optimizer_switch_eng_cond_pushdown2.test:
Check how --engine-condition-pushdown and --optimizer-switch influence each other when used together (last wins).
sql/mysql_priv.h:
new "engine_condition_pushdown" switch in @@optimizer_switch, on by default, like
@@engine_condition_pushdown is on by default. Constants are ULL because optimizer_switch
is stored in a ulonglong.
sql/mysqld.cc:
Making --engine-condition-pushdown and --optimizer-switch (command-line options)
influence each other (last wins)
sql/records.cc:
@@engine_condition_pushdown is deprecated, use @@optimizer_switch instead
sql/sql_select.cc:
@@engine_condition_pushdown is deprecated, use @@optimizer_switch instead
sql/sys_vars.cc:
Setting @@engine_condition_pushdown now issues a deprecation message. The version for removal
is unknown at this point so I copied it from other deprecation warnings in this file.
Turning on/off the engine_condition_pushdown flag of @@optimizer_switch (with SET) turns on/off the @@engine_condition_pushdown variable, and vice-versa, thanks to fix_* functions.
Subtraction of two unsigned months yielded a (very large) positive value.
Conversion of this to a signed value was not necessarily well defined.
Solution: do the subtraction on signed values.
mysql-test/r/events_scheduling.result:
Add test case.
mysql-test/t/events_scheduling.test:
Add test case.
sql/event_data_objects.cc:
Convert month to signed before doing the subtraction.
"set engine_condition_pushdown" is deprecated, engine condition pushdown is controlled
by a new "set optimizer_switch=engine_condition_pushdown=on|off".
mysql-test/r/index_merge_myisam.result:
@@optimizer_switch has a new flag
mysql-test/r/mysqld--help-notwin.result:
@@optimizer_switch has a new flag
mysql-test/r/mysqld--help-win.result:
@@optimizer_switch has a new flag
mysql-test/r/optimizer_switch_eng_cond_pushdown1.result:
Check how --engine-condition-pushdown and --optimizer-switch influence each other when used together (last wins).
mysql-test/r/optimizer_switch_eng_cond_pushdown2.result:
Check how --engine-condition-pushdown and --optimizer-switch influence each other when used together (last wins).
mysql-test/suite/ndb/r/ndb_condition_pushdown.result:
@@engine_condition_pushdown is deprecated, use @@optimizer_switch instead
mysql-test/suite/ndb/r/ndb_gis.result:
@@engine_condition_pushdown is deprecated, use @@optimizer_switch instead
mysql-test/suite/ndb/r/ndb_index_unique.result:
@@engine_condition_pushdown is deprecated, use @@optimizer_switch instead
mysql-test/suite/ndb/t/ndb_condition_pushdown.test:
@@engine_condition_pushdown is deprecated, use @@optimizer_switch instead
mysql-test/suite/ndb/t/ndb_gis.test:
@@engine_condition_pushdown is deprecated, use @@optimizer_switch instead
mysql-test/suite/ndb/t/ndb_index_unique.test:
@@engine_condition_pushdown is deprecated, use @@optimizer_switch instead
mysql-test/suite/sys_vars/r/engine_condition_pushdown_basic.result:
Setting @@engine_condition_pushdown gives a deprecation warning now.
We test that the engine_condition_pushdown flag of @@optimizer_switch, and @@engine_condition_pushdown
influence each other (turning the flag on/off sets the variable on/off and vice-versa).
mysql-test/suite/sys_vars/r/optimizer_switch_basic.result:
@@optimizer_switch has a new flag
mysql-test/suite/sys_vars/t/engine_condition_pushdown_basic.test:
Setting @@engine_condition_pushdown gives a deprecation warning now.
We test that the engine_condition_pushdown flag of @@optimizer_switch, and @@engine_condition_pushdown
influence each other (turning the flag on/off sets the variable on/off and vice-versa).
mysql-test/t/optimizer_switch_eng_cond_pushdown1-master.opt:
Check how --engine-condition-pushdown and --optimizer-switch influence each other when used together (last wins).
mysql-test/t/optimizer_switch_eng_cond_pushdown1.test:
Check how --engine-condition-pushdown and --optimizer-switch influence each other when used together (last wins).
mysql-test/t/optimizer_switch_eng_cond_pushdown2-master.opt:
Check how --engine-condition-pushdown and --optimizer-switch influence each other when used together (last wins).
mysql-test/t/optimizer_switch_eng_cond_pushdown2.test:
Check how --engine-condition-pushdown and --optimizer-switch influence each other when used together (last wins).
sql/mysql_priv.h:
new "engine_condition_pushdown" switch in @@optimizer_switch, on by default, like
@@engine_condition_pushdown is on by default. Constants are ULL because optimizer_switch
is stored in a ulonglong.
sql/mysqld.cc:
Making --engine-condition-pushdown and --optimizer-switch (command-line options)
influence each other (last wins)
sql/records.cc:
@@engine_condition_pushdown is deprecated, use @@optimizer_switch instead
sql/sql_select.cc:
@@engine_condition_pushdown is deprecated, use @@optimizer_switch instead
sql/sys_vars.cc:
Setting @@engine_condition_pushdown now issues a deprecation message. The version for removal
is unknown at this point so I copied it from other deprecation warnings in this file.
Turning on/off the engine_condition_pushdown flag of @@optimizer_switch (with SET) turns on/off the @@engine_condition_pushdown variable, and vice-versa, thanks to fix_* functions.
In auto-commit mode, updating both trx and non-trx tables (i.e. issuing a mixed
statement) causes the following sequence of events:
1 - "Flush trx changes" (MYSQL_BIN_LOG::write) - T1:
1.1 - mutex_lock (&LOCK_log)
1.2 - mutex_lock (&LOCK_prep_xids)
1.3 - increase prepared_xids
1.4 - mutex_unlock (&LOCK_prep_xids)
1.5 - mutex_unlock (&LOCK_log)
2 - "Flush non-trx changes" (MYSQL_BIN_LOG::write) - T1:
2.1 - mutex_lock (&LOCK_log)
2.2 - mutex_unlock (&LOCK_log)
3. "unlog" - T1
3.1 - mutex_lock (&LOCK_prep_xids)
3.2 - decrease prepared xids
3.3 - pthread_cond_signal(&COND_prep_xids);
3.4 - mutex_unlock (&LOCK_prep_xids)
The "FLUSH logs" command produces the following sequence of events:
1 - "FLUSH logs" command (MYSQL_BIN_LOG::new_file_impl) - user thread:
1.1 - mutex_lock (&LOCK_log)
1.2 - mutex_lock (&LOCK_prep_xids)
1.3 - while (prepared_xids) pthread_cond_wait(..., &LOCK_prep_xids);
1.4 - mutex_unlock (&LOCK_prep_xids)
1.5 - mutex_unlock (&LOCK_log)
A deadlock will arise if T1 flushes the trx changes and thus increases
prepared_xids but before it is able to continue the execution and flush the
non-trx changes, an user thread calls the "FLUSH logs" command and wait that
the prepared_xids is decreased and gets to zero. However, T1 cannot proceed
with the call to "Flush non-trx changes" because it will block in the mutex
"LOCK_log" and by consequence cannot complete the execution and call the
unlog to decrease the prepared_xids.
To fix the problem, we ensure that the non-trx changes are always flushed
before the trx changes.
Note that if you call "Flush non-trx changes" and a concurrent "FLUSH logs" is
issued, the "Flush non-trx changes" may block, but a deadlock will never happen
because the prepared_xids will eventually get to zero. Bottom line, there will
not be any transaction able to increase the prepared_xids because they will
block in the mutex "LOCK_log" (MYSQL_BIN_LOG::write) and those that increased
the prepared_xids will eventually commit and decrease the prepared_xids.
