1. 09 Mar, 2004 1 commit
  2. 16 Feb, 2004 5 commits
  3. 14 Feb, 2004 1 commit
  4. 13 Feb, 2004 1 commit
  5. 12 Feb, 2004 8 commits
  6. 11 Feb, 2004 1 commit
  7. 10 Feb, 2004 4 commits
  8. 09 Feb, 2004 3 commits
    • heikki@hundin.mysql.fi's avatar
      row0mysql.c: · d9790a40
      heikki@hundin.mysql.fi authored
        Allow always DROPping of a table which is only referenced by FOREIGN KEY constraints from the same table
      Many files:
        Do not let REPLACE to perform internally an UPDATE if the table is referenced by a FOREIGN KEY: the manual says that REPLACE must resolve a duplicate key error semantically with DELETE(s) + INSERT, and not by an UPDATE; the internal update caused foreign key checks and cascaded operations to behave in a semantically wrong way
      d9790a40
    • heikki@hundin.mysql.fi's avatar
      row0mysql.c: · d2d1e6f7
      heikki@hundin.mysql.fi authored
        Fix crash in InnoDB RENAME TABLE if 'databasename/tablename' is shorter than 5 characters (Bug #2689); reported by Sergey Petrunia
      d2d1e6f7
    • konstantin@mysql.com's avatar
      follow-up to bug #2628: attempt to make · 3d039e49
      konstantin@mysql.com authored
      alter table rename a bit more efficient in case of
      lower_case_table_names.
      3d039e49
  9. 08 Feb, 2004 2 commits
    • heikki@hundin.mysql.fi's avatar
      Many files: · 836e0b05
      heikki@hundin.mysql.fi authored
        Fix bug #2167: generate foreign key id's locally for each table, in the form databasename/tablename_ibfk_number; if the user gives the constraint name explicitly remember it; these changes should ensure that foreign key id's in a slave are the same as in the master, and DROP FOREIGN KEY does not break replication
      sync0sync.c:
        UNIV_SYNC_DEBUG caused assertion in the creation of the doublewrite buffer, if we do not allow thousands of latches per thread
      836e0b05
    • heikki@hundin.mysql.fi's avatar
      ha_innodb.cc: · d7b9d5c9
      heikki@hundin.mysql.fi authored
        If AUTOCOMMIT=1, then we do not need to make a plain SELECT set shared locks even on the SERIALIZABLE isolation level, because we know the transaction is read-only: a read-only transaction can always be performed on the REPEATABLE READ level, and that does not endanger the serializability
      d7b9d5c9
  10. 06 Feb, 2004 6 commits
  11. 05 Feb, 2004 8 commits