A few problems were found in the fix for bug 43668:
1) Comparison of the YEAR column with NULL always returned TRUE;
2) Comparison of the YEAR column with constants always returned
unpredictable result;
3) Unnecessary conversion warnings when comparing a non-integer
constant with a NULL value in the YEAR column;
The problems described above have been resolved with an
exception: zero (i.e. invalid) YEAR column value comparison
with 00 or 2000 still fail (it is not a regression and it was
not a regression), so MIN/MAX on YEAR column containing zero
value still fail.
mysql-test/r/type_year.result:
Test case for bug #49480.
mysql-test/t/type_year.test:
Test case for bug #49480.
sql/item_cmpfunc.cc:
- The get_year_value() function has been modified to make its
return value compatible with the get_datetime_value() return
value (i.e. to convert numeric values into the YYYY0000000000
(YYYY-00-00 00:00:00) form.
- The Arg_comparator::set_cmp_func method has been modified to
use the get_year_value function if get_datetime_value() is not
applicable.
From now only 2 cases have a special processing there:
* both comparing items have MYSQL_TYPE_YEAR field type
or
* one item have is MYSQL_TYPE_YEAR and other one is
is_datetime()-compliant.
- New helper function try_year_cmp_func() has been
added for the better code readability to call from
Arg_comparator::set_cmp_func().
- The Arg_comparator::compare_year method has been removed
since get_year_value() is compatible with the old
Arg_comparator::compare_datetime method that doesn't have
problems #1-#3 (see whole patch entry commentary).
sql/item_cmpfunc.h:
- New helper function try_year_cmp_func() has been
added for the better code readability to call from
Arg_comparator::set_cmp_func().
- Unnecessary Arg_comparator::year_as_datetime and
Arg_comparator::compare_year() declarations have been
removed.
This fix has been proposed by Sergey Petrunya and has been contributed
under SCA by sca@askmonty.org.
The cause for this valgrind error is that in the function
add_cond_and_fix() in sql_select.cc an Item_cond_and object is
created. This is marked as fixed but does not have a correct
table_map() attribute. Later, in make_join_select(), if
engine_condition_pushdown is in use, this table map is used and
results in the valgrind error.
The fix is to add a call to update_used_tables() in add_cond_and_fix()
so that the table map is updated correctly.
This patch is tested by multiple existing tests (e.g. the tests
innodb_mysql, innodb, fulltext, compress all produces this valgrind
warning/error without this fix).
sql/sql_select.cc:
In add_cond_and_fix() add a call to update_used_tables() to ensure
the table map is updated.
There are three issues that caused rpl_killed_ddl fails sporadically
in pb2:
1) thd->clear_error() was not called before create Query event
if operation is executed successfully.
2) DATABASE d2 might do exist because the statement to CREATE or
ALTER it was killed
3) because of bug 43353, kill the query that do DROP FUNCTION or
DROP PROCEDURE can result in SP not found
This patch fixed all above issues by:
1) Called thd->clear_error() if the operation succeeded.
2) Add IF EXISTS to the DROP DATABASE d2 statement
3) Temporarily disabled testing DROP FUNCTION/PROCEDURE IF EXISTS.
mysql-test/t/rpl_killed_ddl.test:
DATABASE d2 might not exists, add IF EXITS to the DROP statement
sql/sql_db.cc:
Called thd->clear_error() if the operation succeeded
{PROCEDURE|FUNCTION} FROM ...'
The master would hit an assertion when binary log was
active. This was due to the fact that the thread's diagnostics
area was being cleared before writing to the binlog,
independently of mysql_routine_grant returning an error or
not. When mysql_routine_grant was to return an error, the return
value and the diagnostics area contents would
mismatch. Consequently, neither my_ok would be called nor an
error would be signaled in the diagnostics area, eventually
triggering the assertion in net_end_statement.
We fix this by not clearing the diagnostics area at binlogging
time.
solaris after a crash
This patch adds a Solaris-specific version of
print_stacktrace() which uses printstack(2), available on all
Solaris versions since Solaris 9. (While Solaris 11 adds
support for the glibc functions backtrace_*() as of
PSARC/2007/162, printstack() is used for consistency over all
Solaris versions.)
The symbol names are mangled, so use of c++filt may be
required as described in the MySQL documentation.
sql/stacktrace.c:
Added Solaris-specific print_stacktrace().
The problem was that the multiple evaluations of a ENCODE or
DECODE function within a single statement caused the random
generator to be reinitialized at each evaluation, even though
the parameters were constants.
The solution is to initialize the random generator only once
if the password (seed) parameter is constant.
This patch borrows code and ideas from Georgi Kodinov's patch.
mysql-test/r/func_str.result:
Add test case result.
mysql-test/r/ps.result:
Add test case result.
mysql-test/t/func_str.test:
Add test case for Bug#49141
mysql-test/t/ps.test:
Add test case for Bug#49141
sql/item_strfunc.cc:
Move seed generation code to a separate method.
Seed only once if the password (seed) argument
is constant.
Remove duplicated code and use a transform method
to apply encoding or decoding.
sql/item_strfunc.h:
Add parameter to signal whether the PRNG is already seeded.
Introduce transform method.
Combine val_str methods.
sql/sql_crypt.cc:
Remove method.
sql/sql_crypt.h:
Seed is supplied as two long integers.
This patch fixes three bugs as follows. First, aborting the server while purging
binary logs might generate orphan files due to how the purge operation was
implemented:
(purge routine - sql/log.cc - MYSQL_BIN_LOG::purge_logs)
1 - register the files to be removed in a temporary buffer.
2 - update the log-bin.index.
3 - flush the log-bin.index.
4 - erase the files whose names where register in the temporary buffer
in step 1.
Thus a failure while executing step 4 would generate an orphan file. Second,
a similar issue might happen while creating a new binary as follows:
(create routine - sql/log.cc - MYSQL_BIN_LOG::open)
1 - open the new log-bin.
2 - update the log-bin.index.
Thus a failure while executing step 1 would generate an orphan file.
To fix these issues, we record the files to be purged or created before really
removing or adding them. So if a failure happens such records can be used to
automatically remove dangling files. The new steps might be outlined as follows:
(purge routine - sql/log.cc - MYSQL_BIN_LOG::purge_logs)
1 - register the files to be removed in the log-bin.~rec~ placed in
the data directory.
2 - update the log-bin.index.
3 - flush the log-bin.index.
4 - delete the log-bin.~rec~.
(create routine - sql/log.cc - MYSQL_BIN_LOG::open)
1 - register the file to be created in the log-bin.~rec~
placed in the data directory.
2 - open the new log-bin.
3 - update the log-bin.index.
4 - delete the log-bin.~rec~.
(recovery routine - sql/log.cc - MYSQL_BIN_LOG::open_index_file)
1 - open the log-bin.index.
2 - open the log-bin.~rec~.
3 - for each file in log-bin.~rec~.
3.1 Check if the file is in the log-bin.index and if so ignore it.
3.2 Otherwise, delete it.
The third issue can be described as follows. The purge operation was allowing
to remove a file in use thus leading to the loss of data and possible
inconsistencies between the master and slave. Roughly, the routine was only
taking into account the dump threads and so if a slave was not connect the
file might be delete even though it was in use.
When checking for an error after removing the special view error handler the code
was not taking into account that open_tables() may fail because of the current
statement being killed.
Added a check for thd->killed.
Added a client program to test it.
Problem: Item_char_typecast reported wrong max_length when
casting to BINARY, which lead, in particular, in wrong
"ORDER BY BINARY(char_column)" results.
Fix: making Item_char_typecast report correct max_length.
@ mysql-test/r/ctype_utf16.result
Fixing old incorrect test result.
@ mysql-test/r/ctype_utf32.result
Fixing old incorrect test result.
@ mysql-test/r/ctype_utf8.result
Adding new test
@ mysql-test/t/ctype_utf8.test
Adding new test
@ sql/item_timefunc.cc
Making Item_char_typecast report correct max_length
when cast is done to BINARY.
Problem: SHOW CREATE FUNCTION and SELECT DTD_IDENTIFIER FROM I_S.ROUTINES
returned wrong values in case of ENUM return data type and UCS2
character set.
Fix: the string to collect returned data type was incorrectly set to
"binary" character set, therefore UCS2 values where returned with
extra '\0' characters.
Setting string character set to creation_ctx->get_client_cs()
in sp_find_routine(), and to system_charset_info in sp_create_routine
fixes the problem.
Adding tests:
- the original test with Latin letters
- an extra test with non-Latin letters
Actually there is two different bugs.
The first one caused crash on queries with WHERE condition over views
containing WHERE condition. A wrong check for prepared statement phase led
to items for view fields being allocated in the execution memory and freed
at the end of execution. Thus the optimized WHERE condition refers to
unallocated memory on the second execution and server crashed.
The second one caused by the Item_cond::compile function not saving changes
it made to the item tree. Thus on the next execution changes weren't
reverted and server crashed on dereferencing of unallocated space.
The new helper function called is_stmt_prepare_or_first_stmt_execute
is added to the Query_arena class.
The find_field_in_view function now uses
is_stmt_prepare_or_first_stmt_execute() to check whether
newly created view items should be freed at the end of the query execution.
The Item_cond::compile function now saves changes it makes to item tree.
mysql-test/r/ps.result:
Added a test case for the bug#48508.
mysql-test/t/ps.test:
Added a test case for the bug#48508.
sql/item_cmpfunc.cc:
Bug#48508: Crash on prepared statement re-execution.
The Item_cond::compile function now saves changes it makes to item tree.
sql/sql_base.cc:
Bug#48508: Crash on prepared statement re-execution.
The find_field_in_view function now uses
is_stmt_prepare_or_first_stmt_execute() to check whether
newly created view items should be freed at the end of the query execution.
sql/sql_class.h:
Bug#48508: Crash on prepared statement re-execution.
The Query_arena::is_stmt_prepare_or_first_sp_execute function now correctly
do its check.
The bug 38816 changed the lock that protects THD::query from
LOCK_thread_count to LOCK_thd_data, but didn't update the associated
InnoDB functions.
1. The innobase_mysql_prepare_print_arbitrary_thd and the
innobase_mysql_end_print_arbitrary_thd InnoDB functions have been
removed, since now we have a per-thread mutex: now we don't need to wrap
several inter-thread access tries to THD::query with a single global
LOCK_thread_count lock, so we can simplify the code.
2. The innobase_mysql_print_thd function has been modified to lock
LOCK_thd_data in direct way.
SET TRANSACTION ISOLATION LEVEL is used to temporarily set
the trans.iso.level for the next transaction. After the
transaction, the iso.level is (re-)set to value of the
session variable 'tx_isolation'.
The bug is caused by setting the thd->variables.tx_isolation
field to the value of the session variable upon each
statement commit. It should only be set at the end of the
full transaction.
The fix has been to remove the setting of the variable in
ha_autocommit_or_rollback if we're in a transaction, as it
will be correctly set in either ha_rollback or
ha_commit_one_phase.
If, on the other hand, we're in autocommit mode, tx_isolation
will be explicitly set here.
mysql-test/t/innodb_mysql.test:
"SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED" sets
the trans.isolation for the next transaction. We test
that @@tx_isolation keeps this value during the transaction,
and is only reset back to the session value at the end
of the transaction.
The 'slave_patternload_file' is assigned to the real path of the load data file
when initializing the object of Relay_log_info. But the path of the load data
file is not formatted to real path when executing event from relay log. So the
error will be encountered if the path of the load data file is a symbolic link.
Actually the global 'opt_secure_file_priv' is not formatted to real path when
loading data from file. So the same thing will happen too.
To fix these errors, the path of the load data file should be formatted to
real path when executing event from relay log. And the 'opt_secure_file_priv'
should be formatted to real path when loading data infile.
mysql-test/suite/rpl/r/rpl_loaddata_symlink.result:
Test result for bug#43913.
mysql-test/suite/rpl/t/rpl_loaddata_symlink-master.sh:
Added the test file to create a link from $MYSQLTEST_VARDIR/std_data
to $MYSQLTEST_VARDIR/std_data_master_link
mysql-test/suite/rpl/t/rpl_loaddata_symlink-slave.sh:
Added the test file to create a link from $MYSQLTEST_VARDIR/std_data
to $MYSQLTEST_VARDIR/std_data_slave_link
mysql-test/suite/rpl/t/rpl_loaddata_symlink.test:
Added the test file to verify if loading data infile will work fine
if the path of the load data file is a symbolic link.
sql/rpl_rli.cc:
Added call 'my_realpath' function for avoiding sometimes the 'fn_format'
function can't format real path rightly.
<tmp_tbl> with RBL
When binlogging the statement, the server always handle the existing
object as a table, even though it is a view. However a view is
handled differently in other parts of the code thus leading the
statement to crash in RBL if the view exists.
This happens because the underlying tables for the view are not opened
when we try to call store_create_info() on the view in order to build
a CREATE TABLE statement.
This patch will only address the crash problem, other binlogging
problems related to CREATE TABLE IF NOT EXISTS LIKE when the existing
object is a view will be solved by BUG 47442.
for each record'
There was an error in an internal structure in the range
optimizer (SEL_ARG). Bad design causes parts of a data
structure not to be initialized when it is in a certain
state. All client code must check that this state is not
present before trying to access the structure's data. Fixed
by
- Checking the state before trying to access data (in
several places, most of which not covered by test case.)
- Copying the keypart id when cloning SEL_ARGs
mysql-test/r/range.result:
Bug#48459: Test result.
mysql-test/t/range.test:
Bug#48459: Test case.
sql/opt_range.cc:
Bug#48459: Fix + doxygenated count_key_part_usage comment.
BUG#46000 - using index called GEN_CLUST_INDEX crashes server
Detailed revision comments:
r6180 | jyang | 2009-11-17 10:54:57 +0200 (Tue, 17 Nov 2009) | 7 lines
branches/5.0: Merge/Port fix for bug #46000 from branches/5.1
-r5895 to branches/5.0. Disallow creating index with the
name of "GEN_CLUST_INDEX" which is reserved for the default
system primary index. Minor adjusts on table name screening
format for added tests.
BUG#47777 - innodb dies with spatial pk: Failing assertion: buf <= original_buf + buf_len
Detailed revision comments:
r6178 | jyang | 2009-11-17 08:52:11 +0200 (Tue, 17 Nov 2009) | 6 lines
branches/5.0: Merge fix for bug #47777 from branches/5.1 -r6045
to bracnches/5.0. Treat the Geometry data same as Binary BLOB
in ha_innobase::store_key_val_for_row(), since the Geometry
data is stored as Binary BLOB in Innodb.
Valgrind reports a conditional jump that depends on uninitialized
data while doing a LOAD DATA and for this test case only. This
test case, tests that loading data from a 4.0 or 4.1 instance
into a 5.1 instance is working. As such it handles old binary log
with a different set of events than currently 5.1 codebase uses.
See the following reference for details:
http://forge.mysql.com/wiki/MySQL_Internals_Binary_Log#LOAD_DATA_INFILE_Events
Problem:
The server is handling an Execute_load_log_event, which results
in reading a Load_log_event from the binary log and applying
it. When applying the Load_log_event, some variable setup is
done and then mysql_load is called. Late in mysql_load
execution, if not in row mode logging, the event is
binlogged write_execute_load_query_log_event.
In write_execute_load_query_log_event, thd->lex->local_file is
inspected. The problem is that it has not been set before in the
execution stack. This causes valgrind to report the warning.
Fix:
We fix this by initializing thd->lex->local_file to be the same
as the value of Load_log_event::local_fname, when lex_start is
called inside Load_log_event::do_apply_event.
In RBR, All statements operating on temporary tables should not be binlogged.
Despite this fact, after executing 'TRUNCATE... ' on a temporary table,
the command is still logged, even if in row-based mode. Consequently, this raises
problems in the slave as the table may not exist, resulting in an
execution failure. Ultimately, this causes the slave to report
an error and abort.
After this patch, 'TRUNCATE ...' statement on a temporary table will not be
binlogged in RBR.
The problem is that the server could crash when attempting
to access a non-conformant proc system table. One such case
was a crash when invoking stored procedure related statements
on a 5.1 server with a proc system table in the 5.0 format.
The solution is to validate the proc system table format
before attempts to access it are made. If the table is not
in the format that the server expects, a message is written
to the error log and the statement that caused the table to
be accessed fails.
mysql-test/r/sp-destruct.result:
Add test case result for Bug#41726
mysql-test/t/sp-destruct.test:
Add test case for Bug#41726
sql/event_db_repository.cc:
Update code to use new structures.
sql/sp.cc:
Describe the proc table format and use it to validate when
opening a instance of the table.
Add a check to insure that a error message is written to
the error log only once.
sql/sql_acl.cc:
Remove unused variable and use new structure.
sql/sql_acl.h:
Export field definition.
sql/table.cc:
Accept the field count and definition in a single structure.
sql/table.h:
Combine the field count and definition in a single structure.
Transform function into a class in order to support different
ways of reporting a error.
Add a pointer cache to TABLE_SHARE.
Not all my_hash_insert() calls are checked for return value.
This patch adds appropriate checks and failure responses
where needed.
mysys/hash.c:
* Debug hook for testing failures in my_hash_insert()
This patch introduce a limit on the time the query cache can
block with a lock on SELECTs.
Other operations which causes a change in the table
data will still be blocked.
sql/sql_cache.cc:
* Introduced a timeout value for the qc lock when entering send_result_to_client()
and store_query() methods.
sql/sql_cache.h:
* New signature for Query_cache::try_lock()
implement Davi's review suggestions (post-push fixes)
include/violite.h:
Use official abbreviation for milliseconds (ms)
sql/mysqld.cc:
Fix formatting
Add error handling for the case of CreateEvent error
vio/vio.c:
Use official abbreviation for milliseconds(ms)
Remove superfluous memset
Fix formatting
vio/viosocket.c:
Use official abbreviation for milliseconds (ms)
Use size_t datatype instead of int in pipe_complete_io
