backup lock should not block partitioned innodb table updates

[Fungo Wang]

Percona Server use a better lightweight solution`LOCK TABLS FOR BACK` and `LOCK BINLOG FOR BACKUP` to substitute 'FLUSH TABLES WITH READ LOCK' in physical backup scene.

The backup lock should not block update to InnoDB tables by design as described in doc: https://www.percona.com/doc/percona-server/LATEST/management/backup_locks.html.

But partition table is not handle properly if the underlying engine is InnoDB, and updates to InnoDB partition table will be block by backup lock.

testcase:
CREATE TABLE t1(id INT, name VARCHAR(30), PRIMARY KEY(id)) ENGINE=InnoDB PARTITION BY HASH(id) PARTITIONS 2;

session A:
lock tables for backup;

session B:
insert into t1 values(1, 'MySQL'); ## will be blocked

session A:
show processlist; ## check session B state is 'Waiting for backup lock'

[Jericho Rivera (jericho-rivera)]

Not reproducible on latest PS 5.7.18-15 using provided test case.

[Jericho Rivera (jericho-rivera)]

Confirmed on latest PS 5.6.36:

mysql> lock tables for backup;
Query OK, 0 rows affected (0.00 sec)

mysql> show processlist;
+----+------+-----------+------+---------+------+-------------------------+-------------------------------+-----------+---------------+
| Id | User | Host | db | Command | Time | State | Info | Rows_sent | Rows_examined |
+----+------+-----------+------+---------+------+-------------------------+-------------------------------+-----------+---------------+
| 2 | root | localhost | test | Query | 0 | init | show processlist | 0 | 0 |
| 3 | root | localhost | test | Query | 5 | Waiting for backup lock | insert into t2 values (1,'s') | 0 | 0 |
+----+------+-----------+------+---------+------+-------------------------+-------------------------------+-----------+---------------+
2 rows in set (0.00 sec)

[Shahriyar Rzayev (rzayev-sehriyar)]

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PS-3713