You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Problem:
This patch is for the second part of the problem where PURGE BINARY LOGS
holds the LOCK_index mutex for long duration and thus affects SHOW
BINARY LOGS as well as blocking purge of both relay and binlog.
Analysis:
The ha_binlog_index_purge_file() callback is called with the LOCK_index
mutex held. When the callback implementation need to do work that takes
some time it will thus block above mentioned commands. While the prior
patch managed to remove lots of work from the callback, the problem
still exists for PURGE BINARY LOGS which should not return until work is
complete.
Solution:
To allow PURGE BINARY LOGS to wait after having released LOCK_index a
new ha_binlog_index_purge_wait() callback is added. The new callback is
only called for PURGE BINARY LOGS and thus making it possible to
preserve the existing synchronous behaviour of the command. Ideally the
ha_binlog_index_purge_file() callback could have been moved to be called
outside of LOCK_index, but the context regarding which file(s) to purge
would then not be available in all code paths. Adding a new callback for
waiting is a much smaller change and affects only the two code paths for
PURGE BINARY LOGS TO and PURGE BINARY LOGS BEFORE. The new callback has
no
effect for storage engines not installing the handlerton::binlog_func
callback.
In addition the mystery code and comment stating that the
ha_binlog_index_purge_file() callback can only be called when LOCK_index
is not already held is removed. The callback should always be called and
then it's up to the storage engine implementor to decide what to do.
Change-Id: I4d19bd9b0a4bfa9820d11ff6d23a4bc4b0ea7e06
0 commit comments