Bug #17876 | Truncating mysql.slow_log in a SP after using cursor locks the thread | ||
---|---|---|---|
Submitted: | 2 Mar 2006 21:16 | Modified: | 2 Aug 2007 17:20 |
Reporter: | Andrey Hristov | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Server: Logging | Severity: | S3 (Non-critical) |
Version: | 5.1.8 BK | OS: | Linux (Suse Linux 10) |
Assigned to: | Marc ALFF | CPU Architecture: | Any |
[2 Mar 2006 21:16]
Andrey Hristov
[8 Mar 2006 8:58]
Magnus BlÄudd
Seems related to bug#17878
[14 Mar 2006 23:49]
MySQL Verification Team
Thank you for the bug report. Correct the test case the create database and create table not matches. CREATE DATABASE IF NOT EXISTS low_log; CREATE TABLE IF NOT EXISTS `slow_log.slow_log_data`
[24 Jul 2007 2:40]
Marc ALFF
Fixed by bug#25422
[27 Jul 2007 18:39]
Marc ALFF
Fixed by Bug#25422
[1 Aug 2007 23:29]
Konstantin Osipov
Fixed in 5.1.21
[2 Aug 2007 17:20]
Paul DuBois
Noted in 5.1.21 changelog. Log table locking was redesigned, eliminating several lock-related problems: - Truncating mysql.slow_log in a stored procedure after use of a cursor caused the thread to lock. (Bug #17876) - Flushing a log table resulted in warnings. (Bug #23044) - The server would hang when performing concurrent ALTER TABLE or TRUNCATE TABLE statements against the log tables. (Bug #25422) - Changing the value of the general_log system variable while a global read lock was in place resulted in deadlock. (Bug #29129)