Re: Replication race bug in sequential file cache (mf_iocache.cc)

Hi!

>>>>> "num" == num writes:

>> Description:
num> If two threads writes to the sequential file cache at the same
num> time, a race condition may occur when accessing the common IO_CACHE
num> *info data structure, since the critical section for updating the info
num> data structure is not protected by any mutexes. The race condition may
num> cause log file corruption because two queries competing about writing to
num> the sequential file cache may be partially written to the cache, causing
num> log file corruption, which in turn causes MySQL replication to abort at
num> the corrupted point in the log file. Note that the MySQL server
num> continues to run after the cache corruption, but data after the
num> corruption never gets replicated, because the replication process or
num> mysqlbinlog exits after finding a corrupted entry.



The above should not be possible as all writes to the cache is
protected by the LOCK_log mutex in sql/log.cc

There may of course be some case were we have missed it, but I would
prefer to know where before trying to patch things in the maybe wrong
place.

If you get a corrupted log, without the MySQL server going done in the
mean time, this does indicate a problem in the IO cache or in the
mutex that protects it.

I checked the code on sql_log.cc and all my_b_write() and
flush_io_cache() call are properly protected by the mutex.
(This is the only place where we write to the binary log file).

Are you 100 % sure that the MySQL didn't go down and that the above
patch fixes this problem ?

Regards,
Monty

------------------------------------------------------------ ---------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)

To request this thread, e-mail bugs-thread12125@lists.mysql.com
To unsubscribe, e-mail