Description:
I realized that the test main.status has an unexpected delay. This delay is determined by file include/wait_condition.inc (see the $wait_counter variable there). However, the test passed successfully, after the countdown finished.
I added a couple of rows to debug the issue (I've attached my patch that reveals things that happen).
Please pay attention to the output of the patched test. In the following output, my connection id is 9. However, the state for this connection id is "executing" instead of the expected state "Waiting for table level lock". That is why the test is waiting for an unexpected time.
CURRENT_TEST: main.status
--- /home/user/rpmbuild/BUILD/mysql-8.0.30/mysql-test/r/status.result 2022-07-07 00:36:34.000000000 +0300
+++ /home/user/rpmbuild/BUILD/mysql-8.0.30/build/mysql-test/var/log/status.reject 2022-11-15 18:37:52.726662817 +0300
@@ -29,6 +29,15 @@
update t1 set n = 3;
# Switched to connection: default
# wait for the second UPDATE to get blocked
+select * from INFORMATION_SCHEMA.PROCESSLIST;
+ID USER HOST DB COMMAND TIME STATE INFO
+9 root localhost test Query 0 executing select * from INFORMATION_SCHEMA.PROCESSLIST
+10 root localhost test Query 0 updating update t1 set n = 3
+11 root localhost test Query 0 User lock update t1 set n = get_lock('mysqltest_lock', 100)
+5 event_scheduler localhost NULL Daemon 1 Waiting on empty queue NULL
+select connection_id();
+connection_id()
+9
Timeout in wait_condition.inc for select 1 from INFORMATION_SCHEMA.PROCESSLIST
where ID = (select connection_id()) and STATE = "Waiting for table level lock"
select release_lock('mysqltest_lock');
mysqltest: Result content mismatch
How to repeat:
1. Apply attached patch (patch-to-debug.diff)
2. run test:
./mysql-test-run.pl --mysqld=--binlog-format=mixed --max-test-fail=5 --report-unstable-tests --mysqld=--skip-innodb-use-native-aio main.status
Description: I realized that the test main.status has an unexpected delay. This delay is determined by file include/wait_condition.inc (see the $wait_counter variable there). However, the test passed successfully, after the countdown finished. I added a couple of rows to debug the issue (I've attached my patch that reveals things that happen). Please pay attention to the output of the patched test. In the following output, my connection id is 9. However, the state for this connection id is "executing" instead of the expected state "Waiting for table level lock". That is why the test is waiting for an unexpected time. CURRENT_TEST: main.status --- /home/user/rpmbuild/BUILD/mysql-8.0.30/mysql-test/r/status.result 2022-07-07 00:36:34.000000000 +0300 +++ /home/user/rpmbuild/BUILD/mysql-8.0.30/build/mysql-test/var/log/status.reject 2022-11-15 18:37:52.726662817 +0300 @@ -29,6 +29,15 @@ update t1 set n = 3; # Switched to connection: default # wait for the second UPDATE to get blocked +select * from INFORMATION_SCHEMA.PROCESSLIST; +ID USER HOST DB COMMAND TIME STATE INFO +9 root localhost test Query 0 executing select * from INFORMATION_SCHEMA.PROCESSLIST +10 root localhost test Query 0 updating update t1 set n = 3 +11 root localhost test Query 0 User lock update t1 set n = get_lock('mysqltest_lock', 100) +5 event_scheduler localhost NULL Daemon 1 Waiting on empty queue NULL +select connection_id(); +connection_id() +9 Timeout in wait_condition.inc for select 1 from INFORMATION_SCHEMA.PROCESSLIST where ID = (select connection_id()) and STATE = "Waiting for table level lock" select release_lock('mysqltest_lock'); mysqltest: Result content mismatch How to repeat: 1. Apply attached patch (patch-to-debug.diff) 2. run test: ./mysql-test-run.pl --mysqld=--binlog-format=mixed --max-test-fail=5 --report-unstable-tests --mysqld=--skip-innodb-use-native-aio main.status