MySQL Bugs: #43089: Connections in 5.1 are released slower than in 5.0

Bug #43089	Connections in 5.1 are released slower than in 5.0
Submitted:	22 Feb 2009 14:49	Modified:	8 Mar 2009 0:58
Reporter:	Elena Stepanova	Email Updates:
Status:	Not a Bug	Impact on me:	None
Category:	MySQL Server	Severity:	S3 (Non-critical)
Version:	5.1.32	OS:	Any
Assigned to:		CPU Architecture:	Any

Description:
High concurrency test with the following parameters passes on 5.0, but fails on 5.1 with 'error 1040: Too many connections'.

perl /export/home/tmp/qauser/extra-5.1/mysql-test/qa-suite/sysb_tests/run_test.pl --base-dir=/export/home/tmp/qauser/bin64_5132 --var-dir=/export/home/tmp/qauser/test_results/5.1.32/high_no_reconnect --sysb-dir=/export/home/tmp/qauser/sysbench-0.5/ --engine=innodb --mysql-param=--mysqld=--innodb --mysql-param=--mysqld=--max_connections=2050 --mysql-param=--mysqld=--max_prepared_stmt_count=20100 --sysb1-test=/export/home/tmp/qauser/extra-5.1/mysql-test/qa-suite/sysb_tests/t/oltp_reconnect_test.lua --sysb2-test=/export/home/tmp/qauser/extra-5.1/mysql-test/qa-suite/sysb_tests/t/oltp_reconnect_test.lua --sysb2-param=--oltp-reconnect-mode=transaction --users1=0 --users2=2000 --duration=300 --row-num=100000

This is a race condition which needs further investigation, because it might be not reliably reproducible. 

How to repeat:
Run high concurrency test with parameters as above (server/test/vardir locations might change).

I think this happens because logging to table is enabled when 5.1 is started via MTR.

I've re-run the test a number of times with and without table logging, with otherwise the same parameters and on the same box, and indeed, the problem always appeared when table logging is switched on, and never when it was disabled.

Since this is a fair difference, and performance degradation is a documented side effect of table logging, I'm switching this to not-a-bug. We only need to make sure that our stress/load tests are not using table logging unless it is specifically required.