>>>>> "Yan" == Yan Zhang Chen <yzc@stripped> writes:
Yan> On Sun, 29 Aug 1999, Michael Widenius wrote:
>> >>>>> "Scott" == Scott Hess <scott@stripped> writes:
Scott> Yan Zhang Chen <yzc@stripped> wrote:
>> >> On Thu, 26 Aug 1999, Scott Hess wrote:
>> >> > We stopped doing it. Do to a misunderstanding, we were using the
>> >> > to lock the table while we copied away the files on disk. We
Scott> to a
>> >> > read lock, and now it works fine.
>> >> The mysqld crash problem seems to happen for either READ or WRITE lock;
>> >> I was using the READ lock when I was reporting this problem early.
Scott> Hmm, this might be a different problem, then. We had a couple test scripts
Scott> that reliably caused the problem with WRITE locks, but never caused it with
Scott> READ locks.
>> This will be fixed in 3.22.26 (We will release this during next week)
Yan> Monty, did I hear you saying this (the problem with LOCK TABLES & FLUSH
Yan> was already fixed in 3.22.25?
Two different bugs :)
The main problem is that flush-tables needs to work on windows (the
problem is that one can't rename or delete files that are in use on windows)
Flush-tables does the following:
- Close all tables not in use
- Mark all tables in use as 'old'.
- Wait until all running statements that uses any table marked as
'old' is done. These are automaticly closed when the statement has ended.
- If any thread tries to open a table that is marked as old and is in
use by some thread, the open will be delayed until the table is not
in use anymore.
- All threads waiting for a 'lock' on an 'old' table, will close the
table as soon as it gets the lock, reopen the table and try to get
the lock again.
The above, combined with threads that has a lock on tables makes
things very tricky and most bugs in recent versions of MySQL has been
in the above code.
3.22.25 fixed a problem with LOCK TABLES + FLUSH TABLES
3.22.26 will fix a problem with LOCK TABLES + DELETE FROM TABLE
(which does a implicit flush-tables on the used table)