11 Commits

Author SHA1 Message Date
Sujatha Sivakumar
df7ecf64f5 Bug#23251517: SEMISYNC REPLICATION HANGING
Revert following bug fix:

Bug#20685029: SLAVE IO THREAD SHOULD STOP WHEN DISK IS
FULL
Bug#21753696: MAKE SHOW SLAVE STATUS NON BLOCKING IF IO
THREAD WAITS FOR DISK SPACE

This fix results in a deadlock between slave IO thread
and SQL thread.
2016-05-13 16:42:45 +05:30
Sujatha Sivakumar
8361151765 Bug#20685029: SLAVE IO THREAD SHOULD STOP WHEN DISK IS
FULL
Bug#21753696: MAKE SHOW SLAVE STATUS NON BLOCKING IF IO
THREAD WAITS FOR DISK SPACE

Problem:
========
Currently SHOW SLAVE STATUS blocks if IO thread waits for
disk space. This makes automation tools verifying
server health block on taking relevant action. Finally this
will create SHOW SLAVE STATUS piles.

Analysis:
=========
SHOW SLAVE STATUS hangs on mi->data_lock if relay log write
is waiting for free disk space while holding mi->data_lock.
mi->data_lock is needed to protect the format description
event (mi->format_description_event) which is accessed by
the clients running FLUSH LOGS and slave IO thread. Note
relay log writes don't need to be protected by
mi->data_lock, LOCK_log is used to protect relay log between
IO and SQL thread (see MYSQL_BIN_LOG::append_event). The
code takes mi->data_lock to protect
mi->format_description_event during relay log rotate which
might get triggered right after relay log write.

Fix:
====
Release the data_lock just for the duration of writing into
relay log.

Made change to ensure the following lock order is maintained
to avoid deadlocks.

data_lock, LOCK_log

data_lock is held during relay log rotations to protect
the description event.
2016-03-01 12:29:51 +05:30
Arun Kuruvila
86375f7fa6 Bug #21370329 : FLUSH DES_KEY_FILE MAY NOT WORK
Description: The command FLUSH DES_KEY_FILE is expected to
reload the DES keys from the file that was specified with
the "--des-key-file" option at server startup. But it is not
behaving as expected.

Analysis: The des file reload is defined within a wrong
conditional directive, rendering the command ineffective.
Macro "OPENSSL" was used instead of "HAVE_OPENSSL" macro.

Fix: "OPENSSL" macro is changed to "HAVE_OPENSSL".
2015-09-22 14:51:48 +05:30
hery.ramilison@oracle.com
85f07c7d7d Merge from mysql-5.5.18-release 2011-11-17 09:00:58 +01:00
Andrei Elkin
a7127418a7 Bug#11763573 - 56299: MUTEX DEADLOCK WITH COM_BINLOG_DUMP, BINLOG PURGE, AND PROCESSLIST/KILL
The bug case is similar to one fixed earlier bug_49536.
Deadlock involving LOCK_log appears to be possible because the purge running thread
is holding LOCK_log whereas there is no sense of doing that and which fact was
exploited by the earlier bug fixes.

Fixed with small reengineering of rotate_and_purge(), adding two new methods and
setting up a policy to execute those instead of the former
rotate_and_purge(RP_LOCK_LOG_IS_ALREADY_LOCKED).
The policy for using rotate(), purge() is that if the caller acquires LOCK_log itself,
it should call rotate(), release the mutex and run purge().

Side effect of this patch is refining error message of bug@11747416 to print
the whole path.
2011-10-27 17:14:41 +03:00
Alexander Nozdrin
bccea2cc5d Manual merge from mysql-5.1-security. 2011-09-23 20:49:23 +04:00
Guilhem Bichot
12f651ac9d Merge from 5.1. 2011-05-21 10:21:08 +02:00
Jon Olav Hauglid
c2dc4b022a Bug #11764779 (former 57649)
FLUSH TABLES under FLUSH TABLES <list> WITH READ LOCK leads 
to assert failure.

This assert was triggered if a statement tried up upgrade a metadata
lock with an active FLUSH TABLE <list> WITH READ LOCK. The assert 
checks that the connection already holds a global intention exclusive
metadata lock. However, FLUSH TABLE <list> WITH READ LOCK does not
acquire this lock in order to be compatible with FLUSH TABLES WITH
READ LOCK. Therefore any metadata lock upgrade caused the assert to
be triggered.

This patch fixes the problem by preventing metadata lock upgrade
if the connection has an active FLUSH TABLE <list> WITH READ LOCK.
ER_TABLE_NOT_LOCKED_FOR_WRITE will instead be reported to the client.

Test case added to flush.test.
2011-03-07 10:08:10 +01:00
Luis Soares
5d6e142b2b BUG#46166
Manual merge from mysql-5.1-bugteam into mysql-5.5-bugteam.

Conflicts
=========

Text conflict in sql/log.cc
Text conflict in sql/log.h
Text conflict in sql/slave.cc
Text conflict in sql/sql_parse.cc
Text conflict in sql/sql_priv.h
2010-12-07 16:11:13 +00:00
Dmitry Lenev
3326614df1 Fix for bug #55273 "FLUSH TABLE tm WITH READ LOCK for Merge
table causes assert failure".

Attempting to use FLUSH TABLE table_list WITH READ LOCK
statement for a MERGE table led to an assertion failure if
one of its children was not present in the list of tables
to be flushed. The problem was not visible in non-debug builds.

The assertion failure was caused by the fact that in such
situations FLUSH TABLES table_list WITH READ LOCK implementation
tried to use (e.g. lock) such child tables without acquiring
metadata lock on them. This happened because when opening tables
we assumed metadata locks on all tables were already acquired
earlier during statement execution and a such assumption was
false for MERGE children.

This patch fixes the problem by ensuring at open_tables() time
that we try to acquire metadata locks on all tables to be opened. 
For normal tables such requests are satisfied instantly since
locks are already acquired for them. For MERGE children metadata
locks are acquired in normal fashion.

Note that FLUSH TABLES merge_table WITH READ LOCK will lock for
read both the MERGE table and its children but will flush only 
the MERGE table. To flush children one has to mention them in table
list explicitly. This is expected behavior and it is consistent with
usage patterns for this statement (e.g. in mysqlhotcopy script).
2010-09-09 18:29:14 +04:00
Konstantin Osipov
4e935a5329 Extract reload_acl_and_cache() and flush_tables_with_read_lock()
into an own implementation file.
2010-08-13 13:51:48 +04:00