Now if CREATE OR REPLACE fails but we have deleted a table already, we will generate a DROP TABLE in the binary log.
This fixes this issue.
In addition, for a failing CREATE OR REPLACE TABLE ... SELECT we don't generate a log of all the inserted rows, only the DROP TABLE.
I added code for not logging DROP TEMPORARY TABLE for tables where the CREATE TABLE was not logged. This code will be activated in 10.1
by removing the code protected by DONT_LOG_DROP_OF_TEMPORARY_TABLES.
mysql-test/suite/rpl/r/create_or_replace_mix.result:
More test cases
mysql-test/suite/rpl/r/create_or_replace_row.result:
More test cases
mysql-test/suite/rpl/r/create_or_replace_statement.result:
More test cases
mysql-test/suite/rpl/t/create_or_replace.inc:
More test cases
sql/log.cc:
Added binlog_reset_cache() to clear the binary log.
sql/log.h:
Added prototype
sql/sql_insert.cc:
If CREATE OR REPLACE TABLE ... SELECT fails:
- Don't log anything if nothing changed
- If table was deleted, log a DROP TABLE.
Remember if we table creation of temporary tables was logged.
sql/sql_table.cc:
Added log_drop_table()
Remember if we table creation of temporary tables was logged.
If CREATE OR REPLACE TABLE ... SELECT fails and a table was deleted, log a DROP TABLE.
sql/sql_table.h:
Added prototype
sql/sql_truncate.cc:
Remember if we table creation of temporary tables was logged.
sql/table.h:
Added table_creation_was_logged
mysql-test/r/create_or_replace2.result:
Added test case
mysql-test/t/create_or_replace.test:
Fixed comment
mysql-test/t/create_or_replace2.test:
Added test case
sql/sql_base.cc:
Safety fix:
Don't let threads with query_id=0 free temporary tables as this may free temporary tables not in use.
This is mostly the case for the slave io threads, as most other threads has thd->query_id != 0.
sql/sql_table.cc:
Added comment.
Ignore kill when opening temporary table for CREATE ... LIKE.
This fixed the original isue
- If an UPDATE 1) modifies the key it is using, and 2) has ORDER BY ... LIMIT
which matches the key it is using, Then we should use "Using buffer", not
"Using filesort".
Automatic merge, except for server_audit.cc that had to be modified slightly
Changes to xtradb and innobase where ignored was these made no sence for 10.0
mysql-test/r/create_or_replace.result:
Added test of releasing of metadata locks
mysql-test/t/create_or_replace.test:
Added test of releasing of metadata locks
sql/handler.h:
Added marker if table was deleted as part of CREATE OR REPLACE
sql/sql_base.cc:
Added Locked_tables_list::unlock_locked_table()
sql/sql_class.h:
New prototypes
sql/sql_insert.cc:
Unlock metadata locks for deleted table in case of error. Also do unlock tables if this was the only locked table.
sql/sql_table.cc:
Unlock metadata locks for deleted table in case of error. Also do unlock tables if this was the only locked table.
Before, the arrival of same GTID twice in multi-source replication
would cause double-apply or in gtid strict mode an error.
Keep the behaviour, but add an option --gtid-ignore-duplicates which
allows to correctly handle duplicates, ignoring all but the first.
This relies on the user ensuring correct configuration so that
sequence numbers are strictly increasing within each replication
domain; then duplicates can be detected simply by comparing the
sequence numbers against what is already applied.
Only one master connection (but possibly multiple parallel worker
threads within that connection) is allowed to apply events within
one replication domain at a time; any other connection that
receives a GTID in the same domain either discards it (if it is
already applied) or waits for the other connection to not have
any events to apply.
Intermediate patch, as proof-of-concept for testing. The main limitation
is that currently it is only implemented for parallel replication,
@@slave_parallel_threads > 0.
Make sure to signal the condition variable for the thread pool after
the new threads have been added to the pool.
Thanks to user nanyi607rao, who reported this bug on maria-developers@.
When an rpl_group_info object was returned from the free list, the
rgi->deferred_events_collecting and rgi->deferred_events was not correctly
re-inited. Additionally, the rgi->deferred_events was incorrectly freed in
free_rgi(), which causes unnecessary malloc/free (or crash when re-init is not
done).
Thanks to user nanyi607rao, who reported this bug on maria-developers@.
Reduced number of my_hash_sort_bin() calls from 4 to 1 per query.
Reduced number of memory accesses done by my_hash_sort_bin().
Details:
- let MDL subsystem use pre-calculated hash value for hash
inserts and deletes
- let table cache use pre-calculated MDL hash value
- MDL namespace is excluded from hash value calculation, so that
hash value can be used by table cache as is
- hash value for MDL is calculated as resulting hash value + MDL
namespace
- extended hash implementation to accept user defined hash function
- Removed double call to trans_begin() for GTID BEGIN event
- Don't set OPTION_BEGIN before calling trans_begin() as this causes extra work in trans_begin()
sql/log_event.cc:
Removed double call to trans_begin for GTID BEGIN event.
Don't set OPTION_BEGIN before calling trans_begin() as this causes extra work in trans_begin().
This was done by removing parsing of "BEGIN" and instead executing trans_begin() direct.
This is much faster, but we lost the ability logging of possible slow "BEGIN" statements. As this should never happen it can be ignored.
The problem was when a GTID event was part of a group commit, and so contained
a commit id. The code that replaces GTID with a BEGIN event for old slaves did
not correctly handle this case.
Fix the code so that the GTID with commit id can also be properly replaced
with a BEGIN query event. The extra two bytes are in the BEGIN event replaced
with a dummy, empty time zone string.
- Make do_fill_table() use join_tab->cache_select->cond if it is present. When
join_tab->cache_select->cond is present, join_tab->select_cond doesn't have any
conditions that are usable for I_S optimizations.
Older master has no GTID events, so such events are not available for
deciding on scheduling of event groups and so on.
With this patch, we run such events from old masters single-threaded, in the
sql driver thread.
This seems better than trying to make the parallel code handle the data from
older masters; while possible, this would require a lot of testing (as well as
possibly some extra overhead in the scheduling of events), which hardly seems
worthwhile.
With parallel replication, there can be any number of events queued on
in-memory lists in the worker threads.
For normal STOP SLAVE, we want to skip executing any remaining events on those
lists and stop as quickly as possible.
However, for START SLAVE UNTIL, when the UNTIL position is reached in the SQL
driver thread, we must _not_ stop until all already queued events for the
workers have been executed - otherwise we would stop too early, before the
actual UNTIL position had been completely reached.
The code did not handle UNTIL correctly, stopping too early due to not
executing the queued events to completion. Fix this, and also implement that
an explicit STOP SLAVE in the middle (when the SQL driver thread has reached
the UNTIL position but the workers have not) _will_ cause an immediate stop.
use the Alter_inplace_info::ALTER_COLUMN_OPTION flag if
field/column flags were altered.
change ha_example to use check_if_supported_inplace_alter() instead
of obsolete check_if_incompatible_data()
Fix ha_table_exists() to take discovery into account correctly.
It must be able to discover both table existence (when no frm is
found) and table non-existance (when frm was found).
That error 'Can't open the pid file' leads to mysqld crash signal 11 in mysql_audit_general() called
with the 'thd' parameter set to NULL. That wasn't checked when the thd->db and thd->db_length
were accessed. Fixed by checking for the NULL thd.
