* Michael Widenius <monty@stripped> [10/06/22 16:42]:
> >>>>> "Konstantin" == Konstantin Osipov <kostja@stripped>
> writes:
> Konstantin> Hello,
> Konstantin> I'm personally convinced that FLUSH TABLES, FLUSH TABLES
> <list>,
> Konstantin> FLUSH TABLES WITH READ LOCK should wait for all started *write*
> Konstantin> (only write) transactions against the involved tables to complete.
>
> To answer this one, we should consider what FLUSH TABLES is used for.
>
> It's main (only?) purposes are
>
> - To allow easy file system level backups of the databases
> - To prepare a database for a snapshot
> - (Optional) Flush things to disk, so that a restart is faster.
>
> In no case above do we need to wait for *write* transactions to
> finish. This is especially true when doing system level snapshots.
Indeed, to get the job done the server (in theory) only needs to
stop new writes from occurring. However, in 5.5, if a connection
already has a metadata lock on the table it's hard to prevent it
from not writing. Harder than just waiting for it to commit and
hence give away its metadata lock.
> The gut feeling is thus that we should not wait for transactions to
> finish for the above commands.
>
> About the mutex; We only take a mutex (at least in 5.1) if there is a
> global read lock active, in which case it doesn't really matter if we
> take one or two mutex. In normal operations there is no mutex, so
> this is no argument for changing the behavior for FLUSH TABLES.
You're looking at lock.cc, where we have a dirty read of global
variable 'global_read_lock'. This is not the main use case
(thankfully), take a look at sql_insert.cc, sql_update.cc, where
we call wait_if_global_read_lock() explicitly.
Besides, even if we forget the code in DML implementations and
trust the dirty read in lock.cc, there is still start_waiting*
function, which takes the mutex in all cases.
--
