LOCK TABLES does not warn/error when unsupported

[morgo]

Feature Request

Is your feature request related to a problem? Please describe:

The table t1 exists, the other table does not:

mysql> LOCK TABLES t1 WRITE;
Query OK, 0 rows affected (0.00 sec)

mysql> LOCK TABLES idontexist WRITE;
Query OK, 0 rows affected (0.00 sec)

In either case, this command is a noop in TiDB, which is unsafe, and breaks a contract with user expectations.

Describe the feature you'd like:

FR 1: This statement should produce an error if the table does not exist.

Option 1: Produce an error (since FLUSH TABLES WITH READ LOCK already errors). This means that mysqldump can no longer restore! This could be addressed via a compatibility mode similar to #10065 will when set downgrades the error to a warning.

Option 2: Produce a warning. This means that a compatibility mode is required. Or alternatively, the compatibility mode could exist but have a different default value to #10065 (default ON).

Option 3: Do nothing. LOCK TABLES as a feature is planned, so we could also consider doing nothing for the interim.

Describe alternatives you've considered:

I lean towards option 2, simply because I think backup restore-ability out of the box is paramount. I could be convinced otherwise.

Teachability, Documentation, Adoption, Migration Strategy:

If a compatibility mode is chosen, the error message should say the mode name. This will help users discover the problem.

[winkyao]

@morgo we are designing the Lock tables and is going to finish the development in the next month. So Do we still need to return a warning for that?

[morgo]

@winkyao If it is one month ago, that is option #3. I think its the best choice, assuming it makes TiDB 3.0.

[winkyao]

Table Lock is supported in this PR #10343, so I close this issue.