MySQL Lists are EOL. Please join:

List:Internals« Previous MessageNext Message »
From:Konstantin Osipov Date:March 17 2009 12:36pm
Subject:Bug#989/WL#4284 "Transactional DDL locking" and prepared statements
View as plain text  

Peter, there are two questions to you below.

After implementation of WL#4284 in 6.0, if one uses a table in a
transaction, it restricts other connections' ability to perform
DDL on the table until the transaction is finished.

One effect of it is that if one does:


-- in one connection,

other connections won't be able to FLUSH, ALTER, or DROP t1 until
the transaction in the first connection commits.

Since we can see both advantages and disadvantages of this
behaviour, for now we decided to not take any action.

How do you think it should work to be user-friendly?
One can always say COMMIT or turn autocommit on if this behaviour
is not desirable.

Peter, is there a standard prescription for this case?
How do other vendors behave?

Note, that the lock is kept till the end of the transaction
regardless of the table storage engine. I.e. even if it is a
MyISAM table, we treat it equally, and won't let concurrent
connections drop it.

Your help and opinions are much appreciated,

Bug#989/WL#4284 "Transactional DDL locking" and prepared statementsKonstantin Osipov17 Mar
  • Re: Bug#989/WL#4284 "Transactional DDL locking" and prepared statementsPeter Gulutzan19 Mar
    • Re: Bug#989/WL#4284 "Transactional DDL locking" and prepared statementsJoerg Bruehe19 Mar