List:Internals« Previous MessageNext Message »
From:Konstantin Osipov Date:June 23 2010 9:38am
Subject:Re: Should FLUSH TABLES WITH READ LOCK wait for updating transactions?
View as plain text  
* 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.

-- 
Thread
Should FLUSH TABLES WITH READ LOCK wait for updating transactions?Konstantin Osipov21 Jun
  • re: Should FLUSH TABLES WITH READ LOCK wait for updating transactions?Michael Widenius22 Jun
    • Re: Should FLUSH TABLES WITH READ LOCK wait for updating transactions?Konstantin Osipov23 Jun
      • Re: Should FLUSH TABLES WITH READ LOCK wait for updating transactions?Michael Widenius24 Jun
    • Re: Should FLUSH TABLES WITH READ LOCK wait for updating transactions?Baron Schwartz24 Jun
      • Re: Should FLUSH TABLES WITH READ LOCK wait for updating transactions?Konstantin Osipov24 Jun
        • Re: Should FLUSH TABLES WITH READ LOCK wait for updating transactions?Baron Schwartz24 Jun
        • Re: Should FLUSH TABLES WITH READ LOCK wait for updating transactions?Rob Wultsch24 Jun
          • Re: Should FLUSH TABLES WITH READ LOCK wait for updating transactions?Konstantin Osipov24 Jun
            • Re: Should FLUSH TABLES WITH READ LOCK wait for updating transactions?Rob Wultsch24 Jun
  • Re: Should FLUSH TABLES WITH READ LOCK wait for updating transactions?MARK CALLAGHAN23 Jun