Description:
In the rpl suite, there is a test loop that inserts a value into a table, but the wrong variable is used to construct the table name. The code snippet:
while ($k) {
let $n = `select floor(rand()*$dbs + 1)`;
let $m = `select floor(rand()*$tables + 1)`;
eval insert into d$n.t$n values (2);
dec $k;
}
Here, the loop uses $n for both the database and table, but the intended behavior is likely to use $m for the table. As a result, the insert may go into an unintended table, causing test failures or incorrect data insertion during automated testing.
How to repeat:
1. Run the rpl_parallel_multi_db test case.
2. Observe the inserts targeting tables that do not match the intended $m variable.
3. Check that the test fails or produces incorrect inserts.
Suggested fix:
Modify the eval line to use the correct table variable $m instead of $n for the table name:
eval insert into d$n.t$m values (2);
Description: In the rpl suite, there is a test loop that inserts a value into a table, but the wrong variable is used to construct the table name. The code snippet: while ($k) { let $n = `select floor(rand()*$dbs + 1)`; let $m = `select floor(rand()*$tables + 1)`; eval insert into d$n.t$n values (2); dec $k; } Here, the loop uses $n for both the database and table, but the intended behavior is likely to use $m for the table. As a result, the insert may go into an unintended table, causing test failures or incorrect data insertion during automated testing. How to repeat: 1. Run the rpl_parallel_multi_db test case. 2. Observe the inserts targeting tables that do not match the intended $m variable. 3. Check that the test fails or produces incorrect inserts. Suggested fix: Modify the eval line to use the correct table variable $m instead of $n for the table name: eval insert into d$n.t$m values (2);