- 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.
Remove memory warnings if mysql client aborts early
Changed copyright for clients
client/mysql.cc:
Free memory if get_options fails, so that we don't get warnings from safemalloc
include/welcome_copyright_notice.h:
Added SkySQL to client copyrights
mysql-test/valgrind.supp:
Added suppressions for memory leaks from dlopen() for OpenSUSE 12.3
storage/oqgraph/mysql-test/oqgraph/regression_mdev5744.result:
Suppress warning
storage/oqgraph/mysql-test/oqgraph/regression_mdev5744.test:
Suppress warning
The problem was that a big record was allocated on the stack, which casued stack to run out.
Fixed by using my_safe_alloca() instead of my_alloca() when allocating records.
Now only records <= 16384 are allocated on the stack.
mysql-test/r/stack-crash.result:
Added test case
mysql-test/t/stack-crash.test:
Added test case
storage/maria/ma_blockrec.c:
Use my_safe_alloca() instead of my_alloca()
storage/maria/ma_dynrec.c:
Use my_safe_alloca() instead of my_alloca()
storage/maria/maria_def.h:
Added MARIA_MAX_RECORD_ON_STACK
storage/maria/maria_pack.c:
Use my_safe_alloca() instead of my_alloca()
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.
my_atomic_load() is implemented as __sync_fetch_and_or(var, 0) which
writes or-ed value back to var. Memory writes as such have worse
performance and scalability than reads.
gcc 4.7 and up offers better facility for atomic loads/stores. Use it
whenever it is available.
The problem was that a big record was allocated on the stack, which casued stack to run out.
Fixed by using my_safe_alloca() instead of my_alloca() when allocating records.
Now only records <= 16384 are allocated on the stack.
mysql-test/r/stack-crash.result:
Added test case
mysql-test/t/stack-crash.test:
Added test case
storage/maria/ma_blockrec.c:
Use my_safe_alloca() instead of my_alloca()
storage/maria/ma_dynrec.c:
Use my_safe_alloca() instead of my_alloca()
storage/maria/maria_def.h:
Added MARIA_MAX_RECORD_ON_STACK
storage/maria/maria_pack.c:
Use my_safe_alloca() instead of my_alloca()
The issue was that create...trigger part of the test suite used a debug_sync point that before was never triggered (in other words, wrong meaningless test).
With the new create ... replace code the debug sync point is triggered and the test case could not handled that.
I fixed this by adding a wait and go for the debug syncpoint in the test.
Removed some compiler warnings from mysql_cond_timedwait
include/mysql/psi/mysql_thread.h:
Removed compiler warnings
mysql-test/r/create-big.result:
New test result
mysql-test/t/create-big.test:
Fixed test case as create_table_select_before_check_if_exists was not before triggered by the code.
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
- MariaDB-5.5 part of the fix: since we can't easily fix query optimization for I_S tables,
run the affected-tablespaces query with semijoin=off. It happens to have a good query plan
with that setting.
[This is a forward-port to MariaDB 10.0]
- 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.
- MariaDB-5.5 part of the fix: since we can't easily fix query optimization for I_S tables,
run the affected-tablespaces query with semijoin=off. It happens to have a good query plan
with that setting.
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.
