- Changed to still use bcmp() in certain cases becasue
- Faster for short unaligneed strings than memcmp()
- Bettern when using valgrind
- Changed to use my_sprintf() instead of sprintf() to get higher portability for old systems
- Changed code to use MariaDB version of select->skip_record()
- Removed -%::SCCS/s.% from Makefile.am:s to remove automake warnings
'CREATE TABLE IF NOT EXISTS ... SELECT' behaviour
BUG#55474, BUG#55499, BUG#55598, BUG#55616 and BUG#55777 are fixed
in this patch too.
This is the 5.1 part.
It implements:
- if the table exists, binlog two events: CREATE TABLE IF NOT EXISTS
and INSERT ... SELECT
- Insert nothing and binlog nothing on master if the existing object
is a view. It only generates a warning that table already exists.
mysql-test/r/trigger.result:
Ather this patch, 'CREATE TABLE IF NOT EXISTS ... SELECT' will not
insert anything if the creating table already exists and is a view.
sql/sql_class.h:
Declare virtual function write_to_binlog() for select_insert.
It's used to binlog 'create select'
sql/sql_insert.cc:
Implement write_to_binlog();
Use write_to_binlog() instead of binlog_query() to binlog the statement.
if the table exists, binlog two events: CREATE TABLE IF NOT EXISTS
and INSERT ... SELECT
sql/sql_lex.h:
Declare create_select_start_with_brace and create_select_pos.
They are helpful for binlogging 'create select'
sql/sql_parse.cc:
Do nothing on master if the existing object is a view.
sql/sql_yacc.yy:
Record the relative postion of 'SELECT' in the 'CREATE ...SELECT' statement.
Record whether there is a '(' before the 'SELECT' clause.
'CREATE TABLE IF NOT EXISTS ... SELECT' behaviour
BUG#55474, BUG#55499, BUG#55598, BUG#55616 and BUG#55777 are fixed
in this patch too.
This is the 5.1 part.
It implements:
- if the table exists, binlog two events: CREATE TABLE IF NOT EXISTS
and INSERT ... SELECT
- Insert nothing and binlog nothing on master if the existing object
is a view. It only generates a warning that table already exists.
After BUG#36649, warnings for sub-statements are cleared when a
new sub-statement is started. This is problematic since it suppresses
warnings for unsafe statements in some cases. It is important that we
always give a warning to the client, because the user needs to know
when there is a risk that the slave goes out of sync.
We fixed the problem by generating warning messages for unsafe statements
while returning from a stored procedure, function, trigger or while
executing a top level statement.
We also started checking unsafeness when both performance and log tables are
used. This is necessary after the performance schema which does a distinction
between performance and log tables.
mysql-test/extra/rpl_tests/create_recursive_construct.inc:
Changed the order of the calls in the procedure because the code
that checks if a warning message is printed out expects that the
first statement gives an warning what is not the case for INSERT
INTO ta$CRC_ARG_level VALUES (47);
mysql-test/suite/binlog/r/binlog_stm_unsafe_warning.result:
Updated the result file.
mysql-test/suite/binlog/r/binlog_unsafe.result:
There are several changes here:
(1) - Changed the CREATE PROCEDURE $CRC.
(2) - The procedure $CRC was failing and the content of the binlog
was being printed out, after fix (1) the failure disappeared.
(3) - The warning message for unsafeness due to auto-increment collumns was
changed.
(4) - The warning message for unsafeness due to VERSION(), RAND() was changed.
mysql-test/suite/binlog/t/binlog_stm_unsafe_warning.test:
Tested filters.
mysql-test/suite/binlog/t/binlog_unsafe.test:
Reenabled the test case binlog_unsafe.
mysql-test/suite/binlog/t/disabled.def:
Reenabled the test case binlog_unsafe.
mysql-test/suite/rpl/r/rpl_begin_commit_rollback.result:
Updated the result file.
mysql-test/suite/rpl/r/rpl_non_direct_stm_mixing_engines.result:
Updated the result file.
mysql-test/suite/rpl/r/rpl_stm_auto_increment_bug33029.result:
Updated the result file.
sql/sql_class.cc:
Moved the stmt_accessed_table_flag variable and related information to the
LEX as we need the variable reset after each statement even inside a stored
procedure, what did not happen if the information was in the THD.
Changed the routine in the THD::binlog_query that prints the warning
messages to avoid trying to print them when inside a stored procedure,
function or trigger.
Checked for unsafeness when both performance and log tables where used.
After the introduction of the performance schema, we need to check both.
After BUG#36649, warnings for sub-statements are cleared when a
new sub-statement is started. This is problematic since it suppresses
warnings for unsafe statements in some cases. It is important that we
always give a warning to the client, because the user needs to know
when there is a risk that the slave goes out of sync.
We fixed the problem by generating warning messages for unsafe statements
while returning from a stored procedure, function, trigger or while
executing a top level statement.
We also started checking unsafeness when both performance and log tables are
used. This is necessary after the performance schema which does a distinction
between performance and log tables.
Incorrect limitation on number of parameters removed.
mysql-test/r/subselect_cache.result:
Test suite added.
mysql-test/t/subselect_cache.test:
Test suite added.
sql/sql_class.h:
Iterator changed.
sql/sql_expression_cache.cc:
Incorrect limitation removed.
Removing NULL references from subquery parameter list added.
******
This patch fixes the following bugs:
- Bug#5889: Exit handler for a warning doesn't hide the warning in
trigger
- Bug#9857: Stored procedures: handler for sqlwarning ignored
- Bug#23032: Handlers declared in a SP do not handle warnings generated
in sub-SP
- Bug#36185: Incorrect precedence for warning and exception handlers
The problem was in the way warnings/errors during stored routine execution
were handled. Prior to this patch the logic was as follows:
- when a warning/an error happens: if we're executing a stored routine,
and there is a handler for that warning/error, remember the handler,
ignore the warning/error and continue execution.
- after a stored routine instruction is executed: check for a remembered
handler and activate one (if any).
This logic caused several problems:
- if one instruction generates several warnings (errors) it's impossible
to choose the right handler -- a handler for the first generated
condition was chosen and remembered for activation.
- mess with handling conditions in scopes different from the current one.
- not putting generated warnings/errors into Warning Info (Diagnostic
Area) is against The Standard.
The patch changes the logic as follows:
- Diagnostic Area is cleared on the beginning of each statement that
either is able to generate warnings, or is able to work with tables.
- at the end of a stored routine instruction, Diagnostic Area is left
intact.
- Diagnostic Area is checked after each stored routine instruction. If
an instruction generates several condition, it's now possible to take a
look at all of them and determine an appropriate handler.
mysql-test/r/signal.result:
Update result file:
1. handled conditions are not cleared any more;
2. reflect changes in signal.test
mysql-test/r/signal_demo3.result:
Update result file: handled conditions are not cleared any more.
Due to playing with max_error_count, resulting warning lists
have changed.
mysql-test/r/sp-big.result:
Update result file: handled conditions are not cleared any more.
mysql-test/r/sp-bugs.result:
Update result file: handled conditions are not cleared any more.
mysql-test/r/sp-code.result:
Update result file:
1. handled conditions are not cleared any more.
2. add result for a new test case in sp-code.test.
mysql-test/r/sp-error.result:
Update result file:
1. handled conditions are not cleared any more.
2. add result for a new test case in sp-error.test.
mysql-test/r/sp.result:
Update result file: handled conditions are not cleared any more.
mysql-test/r/sp_trans.result:
Update result file: handled conditions are not cleared any more.
mysql-test/r/strict.result:
Update result file: handled conditions are not cleared any more.
mysql-test/r/view.result:
Update result file: handled conditions are not cleared any more.
mysql-test/suite/funcs_1/r/innodb_storedproc_02.result:
Update result file: handled conditions are not cleared any more.
mysql-test/suite/funcs_1/r/memory_storedproc_02.result:
Update result file: handled conditions are not cleared any more.
mysql-test/suite/funcs_1/r/myisam_storedproc_02.result:
Update result file: handled conditions are not cleared any more.
mysql-test/suite/funcs_1/r/storedproc.result:
Update result file: handled conditions are not cleared any more.
mysql-test/suite/rpl/r/rpl_row_sp005.result:
Update result file: handled conditions are not cleared any more.
mysql-test/suite/rpl/r/rpl_row_sp006_InnoDB.result:
Update result file: handled conditions are not cleared any more.
mysql-test/suite/rpl/r/rpl_row_trig003.result:
Update result file: handled conditions are not cleared any more.
mysql-test/t/signal.test:
Make a test case more readable in the result file.
mysql-test/t/sp-code.test:
Add a test case for Bug#23032 checking that
No Data takes precedence on Warning.
mysql-test/t/sp-error.test:
Adding test cases for:
- Bug#23032
- Bug#36185
- Bug#5889
- Bug#9857
mysql-test/t/sp.test:
Fixing test case to reflect behavioral changes made by the patch.
sql/sp_head.cc:
Reset the per-statement warning count before executing
a stored procedure instruction.
Move to a separate function code which checks the
completion status of the executed statement and searches
for a handler.
Remove redundant code now that search for a handler is
done after execution, errors are always pushed.
sql/sp_pcontext.h:
Remove unused code.
sql/sp_rcontext.cc:
- Polish sp_rcontext::find_handler(): use sp_rcontext::m_hfound instead
of an extra local variable;
- Remove sp_rcontext::handle_condition();
- Introduce sp_rcontext::activate_handler(), which prepares
previously found handler for execution.
- Move sp_rcontext::enter_handler() code into activate_handler(),
because enter_handler() is used only from there;
- Cleanups;
- Introduce DBUG_EXECUTE_IF() for a test case in sp-code.test
sql/sp_rcontext.h:
- Remove unused code
- Cleanups
sql/sql_class.cc:
Merge THD::raise_condition_no_handler() into THD::raise_condition().
After the patch raise_condition_no_handler() was called
in raise_condition() only.
sql/sql_class.h:
Remove raise_condition_no_handler().
sql/sql_error.cc:
Remove Warning_info::reserve_space() -- handled conditions are not
cleared any more, so there is no need for RESIGNAL to re-push them.
sql/sql_error.h:
Remove Warning_info::reserve_space().
sql/sql_signal.cc:
Handled conditions are not cleared any more,
so there is no need for RESIGNAL to re-push them.
******
This patch fixes the following bugs:
- Bug#5889: Exit handler for a warning doesn't hide the warning in
trigger
- Bug#9857: Stored procedures: handler for sqlwarning ignored
- Bug#23032: Handlers declared in a SP do not handle warnings generated
in sub-SP
- Bug#36185: Incorrect precedence for warning and exception handlers
The problem was in the way warnings/errors during stored routine execution
were handled. Prior to this patch the logic was as follows:
- when a warning/an error happens: if we're executing a stored routine,
and there is a handler for that warning/error, remember the handler,
ignore the warning/error and continue execution.
- after a stored routine instruction is executed: check for a remembered
handler and activate one (if any).
This logic caused several problems:
- if one instruction generates several warnings (errors) it's impossible
to choose the right handler -- a handler for the first generated
condition was chosen and remembered for activation.
- mess with handling conditions in scopes different from the current one.
- not putting generated warnings/errors into Warning Info (Diagnostic
Area) is against The Standard.
The patch changes the logic as follows:
- Diagnostic Area is cleared on the beginning of each statement that
either is able to generate warnings, or is able to work with tables.
- at the end of a stored routine instruction, Diagnostic Area is left
intact.
- Diagnostic Area is checked after each stored routine instruction. If
an instruction generates several condition, it's now possible to take a
look at all of them and determine an appropriate handler.
Remove dead and unused code.
Update to reflect the code review requests.
include/thr_lock.h:
Remove declarations for THR_LOCK_OWNER,
added along with the patch for sensitive cursors.
mysys/thr_lock.c:
Remove support for multiple thr_lock requestors
per THD.
sql/lock.cc:
Revert the patch that added support for sensitive cursors.
sql/sp_rcontext.cc:
Updated the use of mysql_open_cursor().
sql/sql_class.cc:
Move the instance of Server_side_cursor
from class Prepared_statement to class Statement.
sql/sql_class.h:
Move the isntance of Server_side_cursor
from class Prepared_statement to class
Statement.
Remove multiple lock_ids of thr_lock.
sql/sql_cursor.cc:
Remove Sensitive_cursor implementation.
sql/sql_cursor.h:
Remove declarations for sensitive cursors.
sql/sql_prepare.cc:
Move the declaration of instance of Server_side_cursor
from class Statement to class Prepared_statement,
where it's used.
sql/sql_select.cc:
Remove sensitive cursor support.
sql/sql_select.h:
Remove sensitive cursor support.
sql/sql_union.cc:
Remove sensitive cursor support.
If the expression for a virtual column of table contained datetime
comparison then the execution of the second query that used this
virtual column caused a crash. It happened because the execution
of the first query that used this virtual column inserted a cached
item into the expression tree. The cached tree was allocated in
the statement memory while the expression tree was allocated in
the table memory.
Now the cached items that are inserted into expressions for virtual
columns with datetime comparisons are always allocated in the same
mem_root as the expressions for virtual columns. So now the inserted
cached items are valid for any queries that use these virtual columns.
was not cleaned up between PS re-executions. The reason was two-fold:
- a merge with mysql-6.0 missed select_union::cleanup() that should
have cleaned up the temp table, and
- the subclass of select_union used by materialization didn't call
the base class cleanup() method.
1. Changed the lazy optimization for subqueries that can be
materialized into bottom-up optimization during the optimization of
the main query.
The main change is implemented by the method
Item_in_subselect::setup_engine.
All other changes were required to correct problems resulting from
changing the order of optimization. Most of these problems followed
the same pattern - there are some shared structures between a
subquery and its parent query. Depending on which one is optimized
first (parent or child query), these shared strucutres may get
different values, thus resulting in an inconsistent query plan.
2. Changed the code-generation for subquery materialization to be
performed in runtime memory for each (re)execution, instead of in
statement memory (once per prepared statement).
- Item_in_subselect::setup_engine() no longer creates materialization
related objects in statement memory.
- Merged subselect_hash_sj_engine::init_permanent and
subselect_hash_sj_engine::init_runtime into
subselect_hash_sj_engine::init, which is called for each
(re)execution.
- Fixed deletion of the temp table accordingly.
mysql-test/r/subselect_mat.result:
Adjusted changed EXPLAIN because of earlier optimization of subqueries.
