MDEV-13727 top-level query timestamp reset at stored func/trigger internal statements
Being executed under slow_log is ON the test revealed a "side-effect" in MDEV-8305 implementation which inadvertently made the trigger or stored function statements to reset the top-level query's THD::start_time et al. (Details of the test failure analysis are footnoted). Unlike the SP case the SF and Trigger's internal statement should not do that. Fixed with revising the MDEV-8305 decision to backup/reset/restore the session timestamp inside sp_instr_stmt::execute(). The timestamp actually remains reset in the SP case by its caller per statement basis by ever existing logics. Timestamps related tests are extended to cover the trigger and stored function case. Note, commit 3395ab73 is reverted as its struct QUERY_START_TIME_INFO declaration is not in use anymore after this patch. Footnote: -------- Specifically to the failing test, a query on the master was logged okay with a timestamp of the query's top-level statement but its post update trigger managed to compute one more (later) timestamp which got inserted into another table. The latter table master-vs-slave no fractional part timestamp discrepancy became evident thanks to different execution time of the trigger combined with the fact of the logged with micro-second fractional part master timestamp was truncated on the slave. On master when the fractional part was close to 1 the trigger execution added up its own latency to overflow to next second value. That's how the master timestamp surprisingly turned out to bigger than the slave's one.
Showing
Please register or sign in to comment