[MDEV-11911] LOCK=NONE not working when adding column Created: 2017-01-25  Updated: 2021-11-29  Resolved: 2021-11-29

Status: Closed
Project: MariaDB Server
Component/s: Data Definition - Alter Table, Documentation
Affects Version/s: 10.2.2
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Michael Mahemoff Assignee: Ian Gilfillan
Resolution: Fixed Votes: 0
Labels: None
Environment:

Ubuntu 16.04



 Description   

I'm trying to add a column to a large table:

ALTER TABLE `users` ADD `seen_count` int, algorithm=INPLACE, lock=NONE

When I run this, other threads selecting a single row from this table (users) are stalled; "show processlist" indicates "Waiting for table metadata lock"

My understanding was "algorithm=INPLACE, lock=NONE" would not lock up other threads. Or, if lock=NONE wasn't supported (though I believe it should be fine here), an error would occur.



 Comments   
Comment by Daniel Black [ 2017-01-27 ]

your assumptions are correct (ref: https://dev.mysql.com/doc/refman/5.7/en/innodb-create-index-overview.html) and based on "Allows Concurrent DML?" LOCK=NONE should be supported.

Comment by Elena Stepanova [ 2017-01-30 ]

Unfortunately, the fact that the spreadsheet claims that something is allowed does not mean that it is allowed all the time.
There used to be a clearly stated limitation on a deeply hidden page in MySQL manual. It used to say this:

During each online DDL ALTER TABLE statement, regardless of the LOCK clause, there are brief periods at the beginning and end requiring an exclusive lock on the table (the same kind of lock specified by the LOCK=EXCLUSIVE clause).

The hidden page still exists, but the limitation is rephrased in a much vaguer way. It doesn't mean that it went away, if you try you'll see that it still takes a metadata lock .

Here is a more detailed explanation from serg:
https://lists.launchpad.net/maria-developers/msg06016.html

Since the question is bound to be raised over and over again, I suggest to document it explicitly in the KB.

Generated at Thu Feb 08 07:53:36 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.