When compiling wiht ./configure --with-ssl=/usr,
which used OPEN_SSL but not YASSL, the code in sql/mysqld.cc
failed to build because of an incomplete performance schema instrumentation.
This fix implements properly the instrumentation for the rwlock
used in openssl_lock_t.
Verified that the code builds, and the ssl + performance schema tests
do pass.
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().
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.
