~maria-captains/maria/10.0 : changes

~maria-captains/maria/10.0 » Changes from revision 4620

From Revision 4506 to 4487

Rev	Summary	Authors	Tags	Date
4506	5.5 merge 5.5 merge	Sergei Golubchik	mariadb-10.0.15	9 years ago
4505	Merge Merge	Sergei Golubchik		9 years ago
4504	MDEV-7118: Anemometer stop working after upgrade to from... MDEV-7118: Anemometer stop working after upgrade to from... When the optimizer considers an option to use Loose Scan, it should still consider UNIQUE keys (Previously, MDEV-4120 disabled loose scan for all kinds of unique indexes. That was wrong) However, we should not use Loose Scan when trying to satisfy "SELECT DISTINCT col1, col2, .. colN" when using an index defined as UNIQU(col1, col2, ... colN).	Sergey Petrunya		9 years ago
4503	MDEV-7074 multi_source.simple test fails in buildbot MDEV-7074 multi_source.simple test fails in buildbot The problem is that the binlog position is updated before Executed_log_entries and Slave_SQL_State. So, it's possible to hit the moment when MASTER_POS_WAIT (and hence sync_with_master) already returned success, but Slave_SQL_State and Executed_log_entries were not modified yet. Fixing it by adding a wait on the expected Executed_log_entries value.	Elena Stepanova		9 years ago
4502	MDEV-6993 Bad results with join comparing DECIMAL and ENUM/S... MDEV-6993 Bad results with join comparing DECIMAL and ENUM/SET columns	Alexander Barkov		9 years ago
4501	MDEV-6978 Bad results with join comparing case insensitive V... MDEV-6978 Bad results with join comparing case insensitive VARCHAR/ENUM/SET expression to a _bin ENUM column	Alexander Barkov		9 years ago
4500	MDEV-6991 GROUP_MIN_MAX optimization is erroneously applied ... MDEV-6991 GROUP_MIN_MAX optimization is erroneously applied in some cases	Alexander Barkov		9 years ago
4499	MDEV-6950 Bad results with joins comparing DATE/DATETIME and... MDEV-6950 Bad results with joins comparing DATE/DATETIME and INT/DECIMAL/DOUBLE/ENUM/VARCHAR columns MDEV-6971 Bad results with joins comparing TIME and DOUBLE/DECIMAL columns Disallow using indexes on non-temporal columns to optimize ref access, range access and table elimination when the counterpart's cmp_type is TIME_RESULT, e.g.: SELECT * FROM t1 WHERE indexed_int_column=time_expression; Only index on a temporal column can be used to optimize temporal comparison operations.	Alexander Barkov		9 years ago
4498	MDEV-7086 main.ctype_cp932 fails in buildbot on a valgrind b... MDEV-7086 main.ctype_cp932 fails in buildbot on a valgrind build Removing a redundant and wrong condition which could access beyond the pattern string range.	Alexander Barkov		9 years ago
4497	MDEV-7116: Dynamic column hangs/segfaults MDEV-7116: Dynamic column hangs/segfaults Going to 'create_new_string:' caused double freeing alloc_plan (there and at 'end:').	sanja at askmonty		9 years ago
4496	MDEV-7121: Parallel slave may hang if master crashes in the ... MDEV-7121: Parallel slave may hang if master crashes in the middle of writing transaction to binlog When a master server restarts, it writes a restart format_description event as the first event in the next binlog file. The parallel slave SQL thread queues a special restart entry for the current worker thread to signal this, so that the worker thread can roll back any prior partial transaction that might have been written to the binlog due to master crashing. This queueing was missing a mysql_cond_signal() to notify the worker thread. This could cause the worker thread to not process the restart entry, and this in turn would cause the SQL thread to hang infinitely waiting for the worker thread to complete processing. Fix by adding the missing wakeup signalling for this case.	Kristian Nielsen		9 years ago
4495	MDEV-7079: rpl.rpl_parallel_temptable fails in valgrind buil... MDEV-7079: rpl.rpl_parallel_temptable fails in valgrind builder The test case rpl.rpl_parallel_temptable deliberately crashes the master server as part of the testing. This makes it unsuitable for Valgrind testing. So make sure that it will be skipped when testing with Valgrind.	Kristian Nielsen		9 years ago
4494	MDEV-7080: rpl.rpl_gtid_crash fails sporadically in buildbot MDEV-7080: rpl.rpl_gtid_crash fails sporadically in buildbot The real problem here was inconsistent handling of entry->commit_errno in MYSQL_BIN_LOG::write_transaction_or_stmt(). Some return paths were setting it to the value of errno, some where not. And the setting was redundant anyway, as it is set consistently by the caller. Fix by consistently setting it in the caller, and not in each return path in the function. The test failure happened because a DBUG_EXECUTE_IF() used in the test case set an entry->commit_errno that was immediately overwritten in the caller with whatever happened to be the value of errno. This could lead to different error message in the .result file.	Kristian Nielsen		9 years ago
4493	MDEV-7083: sys_vars.innodb_sched_priority* tests fail in MDEV-7083: sys_vars.innodb_sched_priority* tests fail in buildbot on work-amd64-valgrind Fixed issue by finding out first the current used priority for both treads and using that seeing did we really change the priority or not.	Jan Lindström		9 years ago
4492	MDEV-6917: Parallel replication: "Commit failed due to failu... MDEV-6917: Parallel replication: "Commit failed due to failure of an earlier commit on which this one depends", but no prior failure seen This bug was seen when parallel replication experienced a deadlock between transactions T1 and T2, where T2 has reached the commit phase and is waiting for T1 to commit first. In this case, the deadlock is broken by sending a kill to T2; that kill error is then later detected and converted to a deadlock error, which causes T2 to be rolled back and retried. The problem was that the kill caused ha_commit_trans() to errorneously call wakeup_subsequent_commits() on T3, signalling it to abort because T2 failed during commit. This is incorrect, because the error in T2 is only a temporary error, which will be resolved by normal transaction retry. We should not signal error to the next transaction until we have executed the code that handles such temporary errors. So this patch just removes the calls to wakeup_subsequent_commits() from ha_commit_trans(). They are incorrect in this case, and they are not needed in general, as wakeup_subsequent_commits() must in any case be called in finish_event_group() to wakeup any transactions that may have started to wait after ha_commit_trans(). And normally, wakeup will in fact have happened earlier, either from the binlog group commit code, or (in case of no binlogging) after the fast part of InnoDB/XtraDB group commit. The symptom of this bug was that replication would break on some transaction with "Commit failed due to failure of an earlier commit on which this one depends", but with no such failure of an earlier commit visible anywhere.	Kristian Nielsen		9 years ago
4491	MDEV-7065: Incorrect relay log position in parallel replicat... MDEV-7065: Incorrect relay log position in parallel replication after retry of transaction The retry of an event group in parallel replication set the wrong value for the end log position of the event that was retried (qev->future_event_relay_log_pos). It was too large by the size of the event, so it pointed into the middle of the following event. If the retry happened in the very last event of the event group, _and_ the SQL thread was stopped just after successfully retrying that event, then the SQL threads's relay log position would be left incorrect. Restarting the SQL thread could then try to read events from a garbage offset in the relay log, usually leading to an error about not being able to read the event.	Kristian Nielsen		9 years ago
4490	MDEV-6775: Wrong binlog order in parallel replication: Inter... MDEV-6775: Wrong binlog order in parallel replication: Intermediate commit The code in binlog group commit around wait_for_commit that controls commit order, did the wakeup of subsequent commits early, as soon as a following transaction is put into the group commit queue, but before any such commit has actually taken place. This causes problems with too early wakeup of transactions that need to wait for prior to commit, but do not take part in the binlog group commit for one reason or the other. This patch solves the problem, by moving the wakeup to happen only after the binlog group commit is completed. This requires a new solution to ensure that transactions that arrive later than the leader are still able to participate in group commit. This patch introduces a flag wait_for_commit::commit_started. When this is set, a waiter can queue up itself in the group commit queue. This way, effectively the wait_for_prior_commit() is skipped only for transactions that participate in group commit, so that skipping the wait is safe. Other transactions still wait as needed for correctness.	Kristian Nielsen		9 years ago
4489	MDEV-6680: Performance of domain_parallel replication is dis... MDEV-6680: Performance of domain_parallel replication is disappointing The code that handles free lists of various objects passed to worker threads in parallel replication handles freeing in batches, to avoid taking and releasing LOCK_rpl_thread too often. However, it was possible for freeing to be delayed to the point where one thread could stall the SQL driver thread due to full queue, while other worker threads might be idle. This could significantly degrade possible parallelism and thus performance. Clean up the batch freeing code so that it is more robust and now able to regularly free batches of object, so that normally the queue will not run full unless the SQL driver thread is really far ahead of the worker threads.	Kristian Nielsen		9 years ago
4488	MDEV-6718: Server crashed in Gtid_log_event::Gtid_log_event ... MDEV-6718: Server crashed in Gtid_log_event::Gtid_log_event with parallel replication The bug occured in parallel replication when re-trying transactions that failed due to deadlock. In this case, the relay log file is re-opened and the events are read out again. This reading requires a format description event of the appropriate version. But the code was using a description event stored in rli, which is not thread-safe. This could lead to various rare races if the format description event was replaced by the SQL driver thread at the exact moment where a worker thread was trying to use it. The fix is to instead make the retry code create and maintain its own format description event. When the relay log file is opened, we first read the format description event from the start of the file, before seeking to the current position. This now uses the same code as when the SQL driver threads starts from a given relay log position. This also makes sure that the correct format description event version will be used in cases where the version of the binlog could change during replication.	Kristian Nielsen		9 years ago
4487	MDEV-7102: Incorrect PSI_stage_info message in SHOW PROCESSL... MDEV-7102: Incorrect PSI_stage_info message in SHOW PROCESSLIST during parallel replication In parallel replication, threads can do two different waits for a prior transaction. One is for the prior transaction to start commit, the other is for it to complete commit. It turns out that the same PSI_stage_info message was errorneously used in both cases (probably a merge error), causing SHOW PROCESSLIST to be misleading. Fix by using correct, distinct message in each case.	Kristian Nielsen		9 years ago