[MDEV-28943] Online alter fails under LOCK TABLE with ER_ALTER_OPERATION_NOT_SUPPORTED_REASON Created: 2022-06-24  Updated: 2023-08-16  Resolved: 2023-03-29

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

Type: Bug Priority: Critical
Reporter: Elena Stepanova Assignee: Sergei Golubchik
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Problem/Incident
causes MDEV-29056 Replica SQL thread stops with 1846 er... Closed
is caused by MDEV-16329 Engine-independent online ALTER TABLE Closed
Relates
relates to MDEV-28808 Test MDEV-16329 (ALTER ONLINE TABLE) ... Stalled

 Description    

create table t (f int);
 
lock table t write;
 
alter table t force, algorithm=copy, lock=none;
 
 
 
# Cleanup
 
drop table t;

bb-10.10-MDEV-16329 cb1f08bd1c

 
mysqltest: At line 3: query 'alter table t force, algorithm=copy, lock=none' failed: ER_ALTER_OPERATION_NOT_SUPPORTED_REASON (1846): LOCK=NONE is not supported. Reason: COPY algorithm requires a lock. Try LOCK=SHARED

If it's expected, it needs to be documented.

 Comments   
Comment by Sergei Golubchik [ 2022-07-01 ]

Generally, independently from algorithm, it does not make sense to specify lock=shared or lock=none under lock tables, because the table is already exclusively locked.

the question is, should be an error "cannot use lock=xxx under lock tables"? a warning "lock=xxx has no effect under lock tables"? or keep the current behavior and silently ignore the lock=xxx clause?

Comment by Elena Stepanova [ 2022-07-01 ]

I don't think we can make it an error easily, at least for lock=shared it already succeeds in the existing versions, so it would be a regression, and not a very well justified one.
A warning does make sense, I suppose.

Comment by Nikita Malyavin [ 2022-07-01 ]

ok

Generated at Thu Feb 08 10:04:39 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.