| Bug #39897 | lock_multi fails in pushbuild: timeout waiting for processlist | ||
|---|---|---|---|
| Submitted: | 7 Oct 2008 8:13 | Modified: | 17 Feb 17:04 |
| Reporter: | Sven Sandberg | ||
| Status: | Closed | ||
| Category: | Tests: Server | Severity: | S2 (Serious) |
| Version: | 5.1, 6.0 | OS: | Any |
| Assigned to: | Davi Arnaut | Target Version: | 5.1 |
| Tags: | sporadic, test failure, pushbuild | ||
| Triage: | Triaged: D3 (Medium) | ||
[7 Oct 2008 8:13]
Sven Sandberg
[16 Dec 2008 11:15]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/61740 2809 Davi Arnaut 2008-12-16 Bug#39897: lock_multi fails in pushbuild: timeout waiting for processlist The problem is that relying on the "Table lock" thread state to detect that a thread is waiting on a lock is race prone. The "Table lock" state change happens before the thread actually tries to grab a lock on a table. The solution is to introduce a new "Waiting for lock" state that is set only when a thread is actually going to wait for a lock. The state is change happens after the thread fails to grab the lock (because it is owned by other thread) and proceeds to wait on a condition.
[15 Jan 15:19]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/63362 2967 Davi Arnaut 2009-01-15 Bug#39897: lock_multi fails in pushbuild: timeout waiting for processlist The problem is that relying on the "Table lock" thread state in its current position to detect that a thread is waiting on a lock is race prone. The "Table lock" state change happens before the thread actually tries to grab a lock on a table. The solution is to move the "Table lock" state so that its set only when a thread is actually going to wait for a lock. The state change happens after the thread fails to grab the lock (because it is owned by other thread) and proceeds to wait on a condition.
[10 Feb 12:30]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/65726 3039 Davi Arnaut 2009-01-15 Bug#39897: lock_multi fails in pushbuild: timeout waiting for processlist The problem is that relying on the "Table lock" thread state in its current position to detect that a thread is waiting on a lock is race prone. The "Table lock" state change happens before the thread actually tries to grab a lock on a table. The solution is to move the "Table lock" state so that its set only when a thread is actually going to wait for a lock. The state change happens after the thread fails to grab the lock (because it is owned by other thread) and proceeds to wait on a condition. modified: mysys/thr_lock.c sql/lock.cc
[10 Feb 16:00]
Davi Arnaut
Queued to 6.0-bugteam
[14 Feb 14:00]
Bugs System
Pushed into 6.0.10-alpha (revid:matthias.leich@sun.com-20090212211028-y72faag15q3z3szy) (version source revid:matthias.leich@sun.com-20090212211028-y72faag15q3z3szy) (merge vers: 6.0.10-alpha) (pib:6)
[14 Feb 18:06]
Paul DuBois
Am I correct in thinking that this adds a new SHOW PROCESSLIST state that should be listed (with a definition) in the manual?
[14 Feb 19:49]
Davi Arnaut
The "Table lock" state already existed. The difference is that this state is now only set when the calling thread must wait for the lock to become available (and remains set for the duration of the wait).
[16 Feb 2:27]
Paul DuBois
Noted in 6.0.10 changelog. Threads were set to the "Table lock" state in such a way that use of this state by other threads to check for a lock wait was subject to a race condition.
[3 Dec 20:06]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/92759 2985 Konstantin Osipov 2009-12-03 Backport of: ------------------------------------------------------------ revno: 3035.4.1 committer: Davi Arnaut <Davi.Arnaut@Sun.COM> branch nick: 39897-6.0 timestamp: Thu 2009-01-15 12:17:57 -0200 message: Bug#39897: lock_multi fails in pushbuild: timeout waiting for processlist The problem is that relying on the "Table lock" thread state in its current position to detect that a thread is waiting on a lock is race prone. The "Table lock" state change happens before the thread actually tries to grab a lock on a table. The solution is to move the "Table lock" state so that its set only when a thread is actually going to wait for a lock. The state change happens after the thread fails to grab the lock (because it is owned by other thread) and proceeds to wait on a condition. This is considered part of work related to WL#4284 "Transactional DDL locking" @ mysys/thr_lock.c Update thread state while waiting for a table lock.
[3 Dec 20:32]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/92761 2985 Konstantin Osipov 2009-12-03 Backport of: ------------------------------------------------------------ revno: 3035.4.1 committer: Davi Arnaut <Davi.Arnaut@Sun.COM> branch nick: 39897-6.0 timestamp: Thu 2009-01-15 12:17:57 -0200 message: Bug#39897: lock_multi fails in pushbuild: timeout waiting for processlist The problem is that relying on the "Table lock" thread state in its current position to detect that a thread is waiting on a lock is race prone. The "Table lock" state change happens before the thread actually tries to grab a lock on a table. The solution is to move the "Table lock" state so that its set only when a thread is actually going to wait for a lock. The state change happens after the thread fails to grab the lock (because it is owned by other thread) and proceeds to wait on a condition. This is considered part of work related to WL#4284 "Transactional DDL locking" @ mysql-test/r/lock_multi.result A style fix. @ mysql-test/r/sp-threads.result Changed output of SHOW PROCESSLIST (new wait state). @ mysql-test/t/lock_multi.test Use a more accurate state description when waiting inside thr_lock.c. @ mysql-test/t/lock_sync.test Use a more accurate state description when waiting inside thr_lock.c. @ mysql-test/t/multi_update.test Use a more accurate state description when waiting inside thr_lock.c. @ mysql-test/t/query_cache_28249.test Use a more accurate state description when waiting inside thr_lock.c. @ mysql-test/t/sp_notembedded.test Use a more accurate state description when waiting inside thr_lock.c. @ mysql-test/t/status.test Use a more accurate state description when waiting inside thr_lock.c. @ mysys/thr_lock.c Update thread state while waiting for a table lock. @ sql/lock.cc State change was moved inside thr_lock.c.
[3 Dec 21:09]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/92767 2985 Konstantin Osipov 2009-12-03 Backport of: ------------------------------------------------------------ revno: 3035.4.1 committer: Davi Arnaut <Davi.Arnaut@Sun.COM> branch nick: 39897-6.0 timestamp: Thu 2009-01-15 12:17:57 -0200 message: Bug#39897: lock_multi fails in pushbuild: timeout waiting for processlist The problem is that relying on the "Table lock" thread state in its current position to detect that a thread is waiting on a lock is race prone. The "Table lock" state change happens before the thread actually tries to grab a lock on a table. The solution is to move the "Table lock" state so that its set only when a thread is actually going to wait for a lock. The state change happens after the thread fails to grab the lock (because it is owned by other thread) and proceeds to wait on a condition. This is considered part of work related to WL#4284 "Transactional DDL locking" Warning: this patch contains an incompatible change. When waiting on a lock in thr_lock.c, the server used to display "Locked" processlist state. After this patch, the state is "Table lock". The new state was actually intended to be display since year 2002, when Monty added it. But up until removal of thd->locked boolean member, this state was ignored by SHOW PROCESSLIST code. @ mysql-test/r/lock_multi.result A style fix. @ mysql-test/r/sp-threads.result Changed output of SHOW PROCESSLIST (new wait state). @ mysql-test/t/lock_multi.test Use a more accurate state description when waiting inside thr_lock.c. @ mysql-test/t/lock_sync.test Use a more accurate state description when waiting inside thr_lock.c. @ mysql-test/t/multi_update.test Use a more accurate state description when waiting inside thr_lock.c. @ mysql-test/t/query_cache_28249.test Use a more accurate state description when waiting inside thr_lock.c. @ mysql-test/t/sp_notembedded.test Use a more accurate state description when waiting inside thr_lock.c. @ mysql-test/t/status.test Use a more accurate state description when waiting inside thr_lock.c. @ mysys/thr_lock.c Update thread state while waiting for a table lock. @ sql/lock.cc State change was moved inside thr_lock.c.
