Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LOCK TABLE T1 write; does not raise error or warning #28967

Closed
Alkaagr81 opened this issue Oct 19, 2021 · 7 comments · Fixed by #29301
Closed

LOCK TABLE T1 write; does not raise error or warning #28967

Alkaagr81 opened this issue Oct 19, 2021 · 7 comments · Fixed by #29301
Assignees
Labels
affects-5.1 This bug affects 5.1.x versions. affects-5.2 This bug affects 5.2.x versions. affects-5.3 This bug affects 5.3.x versions. severity/critical sig/sql-infra SIG: SQL Infra type/bug The issue is confirmed as a bug.

Comments

@Alkaagr81
Copy link
Collaborator

Alkaagr81 commented Oct 19, 2021

Bug Report

Please answer these questions before submitting your issue. Thanks!

1. Minimal reproduce step (Required)

--sesson 1
drop table if exists t1,t2,t3,t11,t12;
CREATE TABLE t1 (a tinyint(3), b tinyint(5));
INSERT INTO t1 VALUES (1,1);
LOCK TABLE t1 write;

--session 2
INSERT INTO t1 VALUES (1,2); --lock wait timeout and eventually fail

2. What did you expect to see? (Required)

This should return an error if not possible:

mysql> INSERT INTO t1 VALUES (1,2);   --lock wait timeout and eventually fail

3. What did you see instead (Required)

--session 1
drop table if exists t1,t2,t3,t11,t12;
CREATE TABLE t1 (a tinyint(3), b tinyint(5));
INSERT INTO t1 VALUES (1,1);
LOCK TABLE t1 write;

--session 2
INSERT INTO t1 VALUES (1,2); --session 2 is still allow to insert data in t1

4. What is your TiDB version? (Required)

 Release Version: v5.2.1                                          +
 Edition: Community                                               +
 Git Commit Hash: cd8fb24c5f7ebd9d479ed228bb41848bd5e97445        +
 Git Branch: heads/refs/tags/v5.2.1                               +
 UTC Build Time: 2021-09-08 02:29:53                              +
 GoVersion: go1.16.4                                              +
 Race Enabled: false                                              +
 TiKV Min Version: v3.0.0-60965b006877ca7234adaced7890d7b029ed1306+
 Check Table Before Drop: false 
(1 row)
@Alkaagr81 Alkaagr81 added the type/bug The issue is confirmed as a bug. label Oct 19, 2021
@morgo
Copy link
Contributor

morgo commented Oct 19, 2021

I took a look into this today. It might be that TiDB needs to permit this syntax to work with restores from mysqldump, but it should be possible to at least return a warning when tidb_enable_noop_funcs is set toOFF. Otherwise users might be led to believe that the table is being locked, and this could lead to data corruption cases.

@morgo morgo changed the title LOCK TABLE T1 write; does not written an error or message LOCK TABLE T1 write; does not raise error or warning Oct 19, 2021
@Defined2014
Copy link
Contributor

/assign

@Defined2014
Copy link
Contributor

The lock/unlock table feature is implemented by #10343 which is controled by enable-table-lock in config file.
After discussed with @crazycs520 , he didn't suggest us default enable this function because it will cause performance degradation.
Maybe we could add warning information when enable-table-lock equals false. What do you think of it? @morgo

@morgo
Copy link
Contributor

morgo commented Nov 1, 2021

The lock/unlock table feature is implemented by #10343 which is controled by enable-table-lock in config file. After discussed with @crazycs520 , he didn't suggest us default enable this function because it will cause performance degradation. Maybe we could add warning information when enable-table-lock equals false. What do you think of it? @morgo

Yes, a warning is much better than noop.

@jebter jebter added the affects-5.3 This bug affects 5.3.x versions. label Nov 3, 2021
@jebter
Copy link

jebter commented Nov 3, 2021

Do we need to adjust the severity to moderate? @morgo @Defined2014

@morgo
Copy link
Contributor

morgo commented Nov 3, 2021

Do we need to adjust the severity to moderate? @morgo @Defined2014

By triage definition it is critical: TiDB is implying that it is locking tables while giving no feedback to users. This has a high chance of leading to data corruption.

@github-actions
Copy link

github-actions bot commented Nov 4, 2021

Please check whether the issue should be labeled with 'affects-x.y' or 'fixes-x.y.z', and then remove 'needs-more-info' label.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
affects-5.1 This bug affects 5.1.x versions. affects-5.2 This bug affects 5.2.x versions. affects-5.3 This bug affects 5.3.x versions. severity/critical sig/sql-infra SIG: SQL Infra type/bug The issue is confirmed as a bug.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants