-
Venkatesh Duggirala authored
Problem: In Pb2 valgrind runs, rpl_parallel_seconds_behind_master is failing. Analysis: Test script is written under the assumption that while calculating seconds behind_master(SBM), one of the workers should be waiting on 't2' lock. It is achieved through executing 'LOCK TABLE t2' directly on slave before 'INSERT INTO t2' query (which was executed on Master) is executed by the slave worker. But the problem is some times slave worker is completing the execution of 'INSERT INTO t2' before the test script executes 'LOCK TABLE t2'. Hence the SBM value is becoming zero instead of the expected 3 seconds and test logic is waiting for SBM to become greater than 3 and it is getting timed out. Fix: Changing the logic in such way that 'LOCK TABLE t2' will always be executed before slave worker sees 'INSERT INTO t2' query.
Venkatesh Duggirala authoredProblem: In Pb2 valgrind runs, rpl_parallel_seconds_behind_master is failing. Analysis: Test script is written under the assumption that while calculating seconds behind_master(SBM), one of the workers should be waiting on 't2' lock. It is achieved through executing 'LOCK TABLE t2' directly on slave before 'INSERT INTO t2' query (which was executed on Master) is executed by the slave worker. But the problem is some times slave worker is completing the execution of 'INSERT INTO t2' before the test script executes 'LOCK TABLE t2'. Hence the SBM value is becoming zero instead of the expected 3 seconds and test logic is waiting for SBM to become greater than 3 and it is getting timed out. Fix: Changing the logic in such way that 'LOCK TABLE t2' will always be executed before slave worker sees 'INSERT INTO t2' query.
Loading