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

Hi!

>>>>> "Nils" == Nils Ulltveit-Moe writes:



Nils> I have not got any log corruption, even after quite heavy load, with
Nils> the patch I mentioned, so I still believe it most probably is a race
Nils> bug when accessing my_b_write(). I am not able to get an overview over
Nils> the locking that is used for my_b_write(), since this function is used
Nils> a lot of places with various locks used in various encapsulating classes.

Yes, my_b_write() is called in a lot of places, but when it comes to
logging the binary log, the only place from where this is done is in
the log.cc file.

Nils> To try to hunt down the bug, I can modify the patch to use
Nils> pthreads_mutex_trylock() instead of pthreads_lock() and then
Nils> deliberately dump core if two processes are inside my_b_write() working
Nils> on the same buffer at the same time. Hopefully the stack trace will
Nils> then be useful to find the bug.

Please do that; It would help us a lot if you can prove that we have a
race condition in the logging code. To get a back trace from where
this happens would of course be of great help.

By the way, when this happened, where in the binary log file was the
error ? (about which position in how big file).

I just want to be sure that this didn't happen around the time when
MySQL started to use a new binary log file.

Regards,
Monty

--
For technical support contracts, goto https://order.mysql.com/
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Mr. Michael Widenius
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, CTO
/_/ /_/\_, /___/\___\_\___/ Helsinki, Finland
<___/ www.mysql.com


------------------------------------------------------------ ---------
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-thread12144@lists.mysql.com
To unsubscribe, e-mail