Description:
Run of full regression test on
- custome build of MySQL 5.036
(some changes around connection-pool)
32 Bit release
- uname -a
SunOS sol10-sparc-a 5.10 Generic sun4u sparc
SUNW,Sun-Fire-V240
SUN SPARC 64 Bit
- mysqld was started with the option
-thread-handling=pool-of-threads
- There was a high load on the testing box.
(in parallel running tests + very likely a compile)
The testcase lock_multi failed.
Mixup of testscript and file with expected results:
connection locker;
create table t1(n int);
insert into t1 values (1);
lock tables t1 write;
connection writer;
send update low_priority t1 set n = 4;
connection reader;
--sleep 2
send select n from t1;
connection locker;
--sleep 2
unlock tables;
connection writer;
reap;
connection reader;
reap;
n
4 <--- We got here a "1" instead.
drop table t1;
1. I was unable to reproduce this testcase failure.
Conclusion: It is rare.
2. There is no proof for a clear server bug like
crash, non sense warning or error message.
There is also a timeframe where a result set
with n = 1 was valid.
3. There is no strict order of command processing
controlled by mysqltest.
Hint: send <command> ->
Send the command to the server, but do not
wait till the response comes in.
Simply proceed with sending the next commands.
4. The presence of the "sleep" commands shows that it
is tried to ensure some order within the processing of
the commands on server side.
I assume that the "sleep 2" between
send update low_priority t1 set n = 4;
and
send select n from t1;
was just too short (much parallel load on testing box)
to ensure that the update is executed first after
the unlock tables.
Therefore I think that the server works correct, but
testcase is weak.
I also guess that this problem does not depend on
MySQL version, OS or hardware.
How to repeat:
Just run lock_multi with high parallel load
till you get the same failure.
Suggested fix:
It should be tried to replace the "sleep 2" by a routine
which checks that the server has made sufficient
progress in processing the update command.
I volunteer for an attempt to write such a routine.
Note: We have some SHOW commands which give a
information about the current state of
sessions. In the moment I do not know if this
information is fine grained enough for
detection of intended command processing state.
Description: Run of full regression test on - custome build of MySQL 5.036 (some changes around connection-pool) 32 Bit release - uname -a SunOS sol10-sparc-a 5.10 Generic sun4u sparc SUNW,Sun-Fire-V240 SUN SPARC 64 Bit - mysqld was started with the option -thread-handling=pool-of-threads - There was a high load on the testing box. (in parallel running tests + very likely a compile) The testcase lock_multi failed. Mixup of testscript and file with expected results: connection locker; create table t1(n int); insert into t1 values (1); lock tables t1 write; connection writer; send update low_priority t1 set n = 4; connection reader; --sleep 2 send select n from t1; connection locker; --sleep 2 unlock tables; connection writer; reap; connection reader; reap; n 4 <--- We got here a "1" instead. drop table t1; 1. I was unable to reproduce this testcase failure. Conclusion: It is rare. 2. There is no proof for a clear server bug like crash, non sense warning or error message. There is also a timeframe where a result set with n = 1 was valid. 3. There is no strict order of command processing controlled by mysqltest. Hint: send <command> -> Send the command to the server, but do not wait till the response comes in. Simply proceed with sending the next commands. 4. The presence of the "sleep" commands shows that it is tried to ensure some order within the processing of the commands on server side. I assume that the "sleep 2" between send update low_priority t1 set n = 4; and send select n from t1; was just too short (much parallel load on testing box) to ensure that the update is executed first after the unlock tables. Therefore I think that the server works correct, but testcase is weak. I also guess that this problem does not depend on MySQL version, OS or hardware. How to repeat: Just run lock_multi with high parallel load till you get the same failure. Suggested fix: It should be tried to replace the "sleep 2" by a routine which checks that the server has made sufficient progress in processing the update command. I volunteer for an attempt to write such a routine. Note: We have some SHOW commands which give a information about the current state of sessions. In the moment I do not know if this information is fine grained enough for detection of intended command processing state.