MDEV-30014 Spider should not second guess server when locking / unlocking
This fixes MDEV-30014, MDEV-29456, MDEV-29667, and MDEV-30049. The server may ask storage engines to unlock when the original sql command is not UNLOCK. This patch makes sure that spider honours these requests, so that the server has the correct idea which tables are locked and which are not. MDEV-29456, MDEV-29667, MDEV-30049: a later LOCK statement would, as the first step, unlock locked tables and clear the OPTION_TABLE_LOCK bit in thd->variables.option_bits, as well as locked_tables_list, indicating no tables are locked. If Spider does not unlock because the sql command is not UNLOCK, and if after this the LOCK statement fails to lock any tables, these indications that no tables are locked remains, so a later UNLOCK TABLES; statement would not try to unlock any table. Causing later statements requiring mdl locks to hang on waiting until lock_wait_timeout (default 1h) has passed. MDEV-30014: when a LOCK statement tries to lock more than one tables, say t2 and t3 as in mdev_30014.test, and t2 succeeds but t3 fails, the sql layer would try to undo by unlocking t2, and again, if Spider does not honour this request, the sql layer would assume t2 has been unlocked, but later actions on t2 or t2's remote table could hang on waiting for the mdl.
Showing
Please register or sign in to comment