An error occurred fetching the project authors.
  1. 09 Feb, 2010 1 commit
  2. 04 Dec, 2009 1 commit
    • Konstantin Osipov's avatar
      Backport of revno ## 2617.31.1, 2617.31.3, 2617.31.4, 2617.31.5, · 0b39c189
      Konstantin Osipov authored
      2617.31.12, 2617.31.15, 2617.31.15, 2617.31.16, 2617.43.1
      - initial changeset that introduced the fix for 
      Bug#989 and follow up fixes for all test suite failures
      introduced in the initial changeset. 
      ------------------------------------------------------------
      revno: 2617.31.1
      committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
      branch nick: 4284-6.0
      timestamp: Fri 2009-03-06 19:17:00 -0300
      message:
      Bug#989: If DROP TABLE while there's an active transaction, wrong binlog order
      WL#4284: Transactional DDL locking
      
      Currently the MySQL server does not keep metadata locks on
      schema objects for the duration of a transaction, thus failing
      to guarantee the integrity of the schema objects being used
      during the transaction and to protect then from concurrent
      DDL operations. This also poses a problem for replication as
      a DDL operation might be replicated even thought there are
      active transactions using the object being modified.
      
      The solution is to defer the release of metadata locks until
      a active transaction is either committed or rolled back. This
      prevents other statements from modifying the table for the
      entire duration of the transaction. This provides commitment
      ordering for guaranteeing serializability across multiple
      transactions.
      
      - Incompatible change:
      
      If MySQL's metadata locking system encounters a lock conflict,
      the usual schema is to use the try and back-off technique to
      avoid deadlocks -- this schema consists in releasing all locks
      and trying to acquire them all in one go.
      
      But in a transactional context this algorithm can't be utilized
      as its not possible to release locks acquired during the course
      of the transaction without breaking the transaction commitments.
      To avoid deadlocks in this case, the ER_LOCK_DEADLOCK will be
      returned if a lock conflict is encountered during a transaction.
      
      Let's consider an example:
      
      A transaction has two statements that modify table t1, then table
      t2, and then commits. The first statement of the transaction will
      acquire a shared metadata lock on table t1, and it will be kept
      utill COMMIT to ensure serializability.
      
      At the moment when the second statement attempts to acquire a
      shared metadata lock on t2, a concurrent ALTER or DROP statement
      might have locked t2 exclusively. The prescription of the current
      locking protocol is that the acquirer of the shared lock backs off
      -- gives up all his current locks and retries. This implies that
      the entire multi-statement transaction has to be rolled back.
      
      - Incompatible change:
      
      FLUSH commands such as FLUSH PRIVILEGES and FLUSH TABLES WITH READ
      LOCK won't cause locked tables to be implicitly unlocked anymore.
      0b39c189
  3. 08 Dec, 2008 1 commit
    • Matthias Leich's avatar
      Fix for Bug#40904 20 tests in 5.1 are disabled in a bad manner · b16ba9aa
      Matthias Leich authored
      - remove totally wrong (syntax) entries from disabled.def
      - remove entries belonging to deleted tests from disabled.def
      - correct the comments (correct the bug mentioned) of entries in disabled.def
      - remove never completed tests which were accidently pushed
      b16ba9aa
  4. 03 Oct, 2008 1 commit
  5. 25 Jul, 2008 1 commit
  6. 24 Apr, 2008 1 commit
  7. 03 Feb, 2008 1 commit
  8. 02 Feb, 2008 1 commit
  9. 11 Dec, 2007 2 commits
  10. 27 Nov, 2007 1 commit
  11. 26 Nov, 2007 1 commit
  12. 15 Oct, 2007 1 commit
  13. 05 Sep, 2007 1 commit
  14. 24 Aug, 2007 1 commit
  15. 15 Jul, 2007 1 commit
  16. 04 Jul, 2007 1 commit
  17. 27 Jun, 2007 1 commit