MySQL Bugs: #8646: MYSQL_LOG::new_file(bool) hangs in pthread_cond

Bug #8646	MYSQL_LOG::new_file(bool) hangs in pthread_cond_wait()
Submitted:	21 Feb 2005 12:31	Modified:	21 Feb 2005 22:16
Reporter:	Marko Mäkelä	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server	Severity:	S1 (Critical)
Version:	5.0.3-bk	OS:	Linux (GNU/Linux)
Assigned to:	Sergei Golubchik	CPU Architecture:	Any

Description:
I tried to run some benchmarks on 5.0.3 today.  To my surprise, the
data load hanged (0% CPU time usage) on the second or third multi-row
INSERT statement.  I had configured max_binlog_size=2M, and the lines
in the SQL dump are about 1 megabyte long.  After I set
max_binlog_size=2048M, the dump seems to load properly.

How to repeat:
Set max_binlog_size to a small value, and feed enough SQL to mysqld in order to have it create another binlog file.

Suggested fix:
Check your locking logic.

Hi!

I have set max binlog size to 2 MB. Apparently, when mysqld should create a new binlog file, it hangs with the stack trace below:

(gdb) bt
#0  0x40065b94 in __pthread_sigsuspend () from /lib/i686/libpthread.so.0
#1  0x400659d8 in __pthread_wait_for_restart_signal ()
   from /lib/i686/libpthread.so.0
#2  0x40061e90 in pthread_cond_wait@GLIBC_2.0 () from /lib/i686/libpthread.so.0
#3  0x0842785b in safe_cond_wait (cond=0x86260e4, mp=0x86260a4,
    file=0x84ba122 "log.cc", line=1310) at thr_mutex.c:202
#4  0x0821c60b in MYSQL_LOG::new_file(bool) (this=0x8623de0, need_lock=false)
    at log.cc:1310
#5  0x0821dfa0 in MYSQL_LOG::write(THD*, st_io_cache*) (this=0x8623de0,
    thd=0x8c70b28, cache=0x8c6a240) at log.cc:1875
#6  0x08219318 in binlog_commit (thd=0x8c70b28, all=true) at log.cc:121
#7  0x08220d43 in MYSQL_LOG::log(THD*, unsigned long long) (this=0x8623de0,
    thd=0x8c70b28, xid=9025) at log.cc:2989
#8  0x0825e528 in ha_commit_trans(THD*, bool) (thd=0x8c70b28, all=true)
    at handler.cc:568
#9  0x081ad8da in end_trans(THD*, enum_mysql_completiontype) (thd=0x8c70b28,
    completion=COMMIT) at sql_parse.cc:1316
#10 0x081b491f in mysql_execute_command(THD*) (thd=0x8c70b28)
    at sql_parse.cc:3846
#11 0x081b8271 in mysql_parse(THD*, char*, unsigned) (thd=0x8c70b28,
    inBuf=0x8c8f588 "commit", length=6) at sql_parse.cc:5158
#12 0x081ae45b in dispatch_command(enum_server_command, THD*, char*, unsigned)
    (command=COM_QUERY, thd=0x8c70b28, packet=0x8c87529 "commit",
    packet_length=7) at sql_parse.cc:1618
#13 0x081adcad in do_command(THD*) (thd=0x8c70b28) at sql_parse.cc:1425
#14 0x081ace34 in handle_one_connection (arg=0x8c70b28) at sql_parse.cc:1081
#15 0x40062f60 in pthread_start_thread () from /lib/i686/libpthread.so.0
#16 0x400630fe in pthread_start_thread_event () from /lib/i686/libpthread.so.0
#17 0x401f5327 in clone () from /lib/i686/libc.so.6
(gdb)

ibtest7a produces this behavior in about 30 seconds. Marko got this same trace with an import of a table dump.

Regards,

Heikki

Thank you for your bug report. This issue has been committed to our
source repository of that product and will be incorporated into the
next release.

If necessary, you can access the source repository and build the latest
available version, including the bugfix, yourself. More information 
about accessing the source trees is available at
    http://www.mysql.com/doc/en/Installing_source_tree.html