Fix remaining issues with wsrep_sync_wait and query cache.
- Fixes misplaced call to invalidate query cache in
Rows_log_event::do_apply_event().
Query cache was invalidated too early, and allowed old
entries to be inserted to the cache.
- Reset thd->wsrep_sync_wait_gtid on query cache hit.
THD->cleanup_after_query is not called in such cases,
and thd->wsrep_sync_wait_gtid remained initialized.
The admin commands in question are:
> OPTIMIZE
> REPAIR
> ANALYZE
For LOCAL or NO_WRITE_TO_BINLOG invocations of these commands, ie
OPTIMIZE LOCAL TABLE <t1>
they are not binlogged as expected.
Also, in addition, they are not executed under TOI.
Hence, they are not propagated to other nodes.
The effect is same as that of wsrep_on=0.
Also added tests for this.
A WSREP_DEBUG for wsrep_register_hton has also been added.
The galera_flush_local test has also been updated for verifying that effects
of NO_WRITE_TO_BINLOG / LOCAL are equivalent to wsrep_on=0 from wsrep
perspective.
(cherry picked from commit 5065122f94a8002d4da231528a46f8d9ddbffdc2)
Conflicts:
sql/sql_admin.cc
sql/sql_reload.cc
sql/wsrep_hton.cc
- Moves call wsrep_free_status() to THD::cleanup_after_query().
Wsrep status variables were previously freed only on SHOW STATUS.
- Removes valgrind suppression from mysql-test/valgrind.
Problem is that FLUSH TABLES WITH READ LOCK first blocks threads from
starting new commits, then waits for running commits to complete. But
in-order parallel replication needs commits to happen in a particular
order, so this can easily deadlock.
To fix this problem, this patch introduces a way to temporarily pause
the parallel replication worker threads. Before starting FTWRL, we let
all worker threads complete in-progress transactions, and then
wait. Then we proceed to take the global read lock. Once the lock is
obtained, we unpause the worker threads. Now commits are blocked from
starting by the global read lock, so the deadlock will no longer occur.
EXPLAIN INSERT ... SELECT tried to use SELECT's execution path. This
caused a collection of problems:
- SELECT_DESCRIBE flag was not put into select_lex->options, which
means it was not in JOIN::select_options either (except for the first
member of the UNION).
- This caused UNION members to be executed. They would attempt to write
join output rows to the output.
- (Actual cause of the crash) second join sibling would call
result->send_eof() when finished execution. Then,
Explain_query::print_explain would attempt to write to query output
again, and cause an assertion due to non-empty query output.
[EXPLAIN] INSERT .. SELECT creates a select_insert object.
select_insert calls handler->start_bulk_insert() during
initialization.
For MyISAM/Aria this requires that a matching call to
handler->end_bulk_insert() call is made.
Regular INSERT .. SELECT accomplishes this by calling either
select_result->send_eof() or select_result->abort_result_set().
EXPLAIN INSERT ... SELECT didn't call either, which resulted in
improper de-initializaiton of handler object. Make it call
abort_result_set(), which invokes handler->end_bulk_insert().
Before this, FLUSH TABLES and FLUSH TABLES t1 (REFRESH_TABLES hereafter) were executed locally,
which also had implications for GTID. MySQL async replication does
replicate FLUSH TABLES.
Hence, this commit
a) Adds REFRESH_TABLES to TOI.
b) Skips LOCK-based REFRESH_TABLES from TOI, ie. FLUSH TABLES WITH READ
LOCK and FLUSH TABLES FOR EXPORT.
c) Executes them after reload_acl_and_cache. This is done since
reload_acl_and_cache checks for thd->locked_tables_mode and does upgrade
of MDL locks accordingly. A failure here means REFRESH_TABLES cannot
run.
i) This is also important since LOCK TABLES is not replicated in
galera.
d) Test galera_flush has been modified for
i) wsrep_replicate_myisam SESSION variable.
ii) Testing REFRESH_TABLES.
iii) Testing REFRESH_TABLES + LOCK TABLES.
e) Use different WSREP_TO_ISOLATION_BEGIN for global FLUSH TABLES and FLUSH TABLES <table,>.
In galera cluster, when myisam replication is enabled
(wsrep_replicate_myisam=ON), DML statements are replicated
in open_tables(). However, in case of prepared statements,
for an INSERT, open_tables() gets invoked twice. Once for
COM_STMT_PREPARE (to validate and prepare INSERT) and later
for COM_STMT_EXECUTE. As a result, the command gets replicated
twice. Same happens for REPLACE, UPDATE and DELETE commands.
Fixed by adding a check to not replicate during 'prepare'
phase. Also changed the order of conditions to make it more
efficient. Lastly, in order to support wsrep_dirty_reads, made
changes to allow COM_STMT_XXX commands to continue past initial
check even when wsrep is not ready.
RENAME TABLE, unlike other DDLs, was getting replicated before
the access check was performed. As a result, the command could
get get replicated and thus executed on other nodes, even if it
fails on the originating node due to permission issues. Fixed by
moving the logic to check user privileges before replicating the
command.
THD::>save_prep_leaf_list was set to true by multi-table update
statements with mergeable selects and never reset.
Make every statement reset it at start.
THD::>save_prep_leaf_list was set to true by multi-table update
statements with mergeable selects and never reset.
Make every statement reset it at start.
[Attempt #] Make the code that handles "Prepare" phase for multi-table
UPDATE statements handle non-merged semijoins. It can encounter them when
a prepared statement is executed for the second time.
DATABASE WHEN USING TABLE ALIASES
Issue:
-----
When using table aliases for deleting, MySQL checks
privileges against the current database and not the
privileges on the actual table or database the table
resides.
SOLUTION:
---------
While checking privileges for multi-deletes,
correspondent_table should be used since it points to the
correct table and database.
Problem :
---------
The specific issue reported in this bug is with range/list column
value that is allocated and initialized by evaluating partition
expression(item tree) during execution. After evaluation the range
list value is marked fixed [part_column_list_val]. During next
execution, we don't re-evaluate the expression and use the old value
since it is marked fixed.
Solution :
----------
One way to solve the issue is to mark all column values as not fixed
during clone so that the expression is always re-evaluated once we
attempt partition_info::fix_column_value_functions() after cloning
the part_info object during execution of DDL on partitioned table.
Reviewed-by: Jimmy Yang <Jimmy.Yang@oracle.com>
Reviewed-by: Mattias Jonsson <mattias.jonsson@oracle.com>
RB: 9424
1. factored XID-related functions to a separate wsrep_xid.cc unit.
2. refactored them to take refrences instead of pointers where appropriate
3. implemented wsrep_get/set_SE_position to take wsrep_uuid_t and wsrep_seqno_t instead of XID
4. call wsrep_set_SE_position() in wsrep_sst_received() to reinitialize SE checkpoint after SST was received, avoid assert() in setting code by first checking current position.
The following FLUSH commands are now executed under total
order isolation:
* FLUSH DES_KEY_FILE
* FLUSH HOSTS
* FLUSH PRIVILEGES
* FLUSH QUERY CACHE
* FLUSH STATUS
* FLUSH USER_RESOURCES
including the big commit
commit 305130361bf72726de220f3d2b2787395e10be61
Author: Marc Alff <marc.alff@oracle.com>
Date: Tue Feb 10 11:31:32 2015 +0100
WL#8354 BACKPORT DIGEST IMPROVEMENTS TO MYSQL 5.6
(with the following commits) and related changes in sql/
The following FLUSH commands are now executed under total
order isolation:
* FLUSH DES_KEY_FILE
* FLUSH HOSTS
* FLUSH PRIVILEGES
* FLUSH QUERY CACHE
* FLUSH STATUS
* FLUSH USER_RESOURCES
This patch was backported from mysql-wsrep/5.6 commit
cdea608d9a27701d76d0deec49976aa0a08b1a56
sql/sql_parse.cc: In function 'bool do_command(THD*)':
sql/sql_parse.cc:758:20: error: 'packet_length' may be used uninitialized in this function [-Werror=maybe-uninitialized]
if ((WSREP(thd) && packet_length == packet_error) ||
[
