wsrep_local_bf_aborts is not incremented if the aborted statement is LOCK TABLE

[Philip Stoev]

If Galera needs to abort a local LOCK TABLE statement in order to satisfy a slave transaction, the wsrep_local_bf_aborts variable is not incremented, even though the LOCK TABLE does fail with a deadlock error.

The counter is properly incremented for all other sorts of statements, e.g. GET_LOCK(), SLEEP(), etc.

Test case:

--source include/galera_cluster.inc
--source include/have_innodb.inc

#
# Test a local transaction being aborted by a slave one while it is running a LOCK TABLE
#

CREATE TABLE t1 (f1 INTEGER PRIMARY KEY) ENGINE=InnoDB;

--connection node_2
SET AUTOCOMMIT=OFF;
--let $wsrep_local_bf_aborts_before = `SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.GLOBAL_STATUS WHERE VARIABLE_NAME = 'wsrep_local_bf_aborts'`
--send LOCK TABLE t1 WRITE;

--connection node_1
INSERT INTO t1 VALUES (1);

--connection node_2
--reap
--error ER_LOCK_DEADLOCK

--let $wsrep_local_bf_aborts_after = `SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.GLOBAL_STATUS WHERE VARIABLE_NAME = 'wsrep_local_bf_aborts'`

# Currently, aborting LOCK TABLE is not counted under wsrep_local_bf_aborts
--disable_query_log
--eval SELECT $wsrep_local_bf_aborts_after - $wsrep_local_bf_aborts_before = 0 AS wsrep_local_aborts_increment;
--enable_query_log

[Philip Stoev (philip-stoev-f)]

Actually the counter is not reliable with LOCK TABLE, sometimes it gets incremented and sometimes not.

This is specific to LOCK TABLE, for all the other statements the counter is reliably incremented.

[Philip Stoev (philip-stoev-f)]

The test was not deterministic so this bug is invalid.

LOCK TABLE is not expected to block, so it was incorrect to run it with --send and --reap