JZuming
Reproduce Question 2
Dear author, we recently encountered an issue while using TxCheck, it appears that TxCheck may generate false positives due to improper decoupling of transaction dependencies, below is an example we observed: During parallel execution, step T1S3 of Txn 1 reads an INSERT committed by step T0S2 of Txn 0. However, during sequential execution, Transaction 1 runs before Transaction 0, and thus T1S3 does not see the INSERT from T0S2.
transaction test 0 T0 S0: START TRANSACTION; 1 T1 S0: START TRANSACTION; 2 T1 S1: SELECT * FROM t_4cioad; 3 T1 S2: select ref_0.wkey as c0, ref_0.pkey as c1, ref_0.c_u5cl7d as c2, ref_0.c_w3yee as c3 fr 4 T0 S1: SELECT * FROM t_5wqatb; 5 T0 S2: insert into t_4cioad (wkey, pkey, c_u5cl7d, c_w3yee) values (113, 591000, SIGN( (select c_q_kflb 6 T0 S3: select t_4cioad.wkey as c0, t_4cioad.pkey as c1, t_4cioad.c_u5cl7d as c2, t_4cioad.c_w3 7 T0 S4: COMMIT; retrying process begin... retrying process end... 8 T1 S3: SELECT * FROM t_4cioad; 9 T1 S4: select t_4cioad.wkey as c0, t_4cioad.pkey as c1, t_4cioad.c_u5cl7d as c2, t_4cioad.c_w3 10 T1 S5: update t_4cioad set wkey = 136, c_u5cl7d = SIGN( PI()) where t_4cioad.c_u5cl7d >= t_4cioad 11 T1 S6: select t_4cioad.wkey as c0, t_4cioad.pkey as c1, t_4cioad.c_u5cl7d as c2, t_4cioad.c_w3 12 T1 S7: COMMIT; retrying process begin... retrying process end... check transaction dependency ... done stmt path for normal test: (1.1)-1IN|->(1.2)-2RW|2OW|->(1.3)-2IN|->(1.4)-1IN|->(1.5)-1IN|->(1.6)-2OW|->(0.1)-1IN|->(0.2)-1IN|->(0.3)--> normal testing ... done stmt[5] output sizes are not equel: 33 31 txn output is not equal to normal stmt one Find bugs in check_normal_stmt_result Succeed to delete stmt
item name: stmt[5] A result: 136 507000 1 9w2ced 136 508000 1 xe5rpc 136 509000 1 zw5rd 136 510000 1 NULL 136 511000 1 ren8yb 136 512000 1 mpyy_c 136 513000 1 3patbb 136 522000 1 nbb0zb 136 523000 1 l_0xzb 136 524000 1 fpcldd 136 525000 1 7sepvc 136 526000 1 hbgnkd 136 527000 1 pex2vc 136 528000 1 6717ld 136 529000 1 yfxfv 136 536000 1 ao8bhd 136 537000 1 ii7s_b 136 538000 1 NULL 136 539000 1 NULL 136 540000 1 ur0ka 136 541000 1 meigrb 136 545000 1 NULL 136 546000 1 NULL 136 547000 1 NULL 136 548000 1 NULL 136 549000 1 NULL 136 550000 1 NULL 136 556000 1 aywidb 136 557000 1 8ohp1 136 558000 1 hh_he 136 559000 1 wmisbc 136 592000 1 0 136 593000 1 t5a48d B result: 136 507000 1 9w2ced 136 508000 1 xe5rpc 136 509000 1 zw5rd 136 510000 1 NULL 136 511000 1 ren8yb 136 512000 1 mpyy_c 136 513000 1 3patbb 136 522000 1 nbb0zb 136 523000 1 l_0xzb 136 524000 1 fpcldd 136 525000 1 7sepvc 136 526000 1 hbgnkd 136 527000 1 pex2vc 136 528000 1 6717ld 136 529000 1 yfxfv 136 536000 1 ao8bhd 136 537000 1 ii7s_b 136 538000 1 NULL 136 539000 1 NULL 136 540000 1 ur0ka 136 541000 1 meigrb 136 545000 1 NULL 136 546000 1 NULL 136 547000 1 NULL 136 548000 1 NULL 136 549000 1 NULL 136 550000 1 NULL 136 556000 1 aywidb 136 557000 1 8ohp1 136 558000 1 hh_he 136 559000 1 wmisbc
We would like to ask whether TxCheck currently accounts for such cases, and if this kind of behavior is expected. Thank you very much for your time and attention.
