1. 26 Feb, 2014 2 commits
  2. 22 Feb, 2014 1 commit
    • Michael Widenius's avatar
      Fixed that rpl_row_create_table can be run with --ps-protocol · 6efa5efa
      Michael Widenius authored
      As part of the fix we don't anymore generate a create table statement when doing a
      CREATE TABLE IF NOT EXISTS table_that_exist LiKE temporary_table
      if the 'table_that_exist' existed.
      
      This is because it's not self evident if we should generate a create statement
      matching the existing table or the temporary_table. 
      The old code generated a table like the existing table in row based replication and like the temporary table
      in statement based replication.
      It's better to ensure that both cases works the same way.
      
      mysql-test/suite/rpl/r/rpl_row_create_table.result:
        Updated results
        (Now we don't anymore CREATE TABLE IF NOT EXISTS LIKE if the table existed)
      sql/sql_base.cc:
        More DBUG_PRINT
      sql/sql_error.cc:
        More DBUG_PRINT
      sql/sql_table.cc:
        Don't generate a create table statement when doing a
        CREATE TABLE IF NOT EXISTS table_that_exist like temporary_table if the table existed.
      6efa5efa
  3. 19 Feb, 2014 1 commit
    • Sergey Vojtovich's avatar
      MDEV-5314 - Compiling fails on OSX using clang · d12c7adf
      Sergey Vojtovich authored
      This is port of fix for MySQL BUG#17647863.
      
      revno: 5572
      revision-id: jon.hauglid@oracle.com-20131030232243-b0pw98oy72uka2sj
      committer: Jon Olav Hauglid <jon.hauglid@oracle.com>
      timestamp: Thu 2013-10-31 00:22:43 +0100
      message:
        Bug#17647863: MYSQL DOES NOT COMPILE ON OSX 10.9 GM
      
        Rename test() macro to MY_TEST() to avoid conflict with libc++.
      d12c7adf
  4. 13 Feb, 2014 3 commits
    • Sergey Vojtovich's avatar
      MDEV-5597 - Reduce usage of LOCK_open: LOCK_flush · fd1437df
      Sergey Vojtovich authored
      Replaced LOCK_flush with per-share conditional variable.
      fd1437df
    • Sergey Vojtovich's avatar
      MDEV-5492 - Reduce usage of LOCK_open: TABLE::in_use · 048e9c40
      Sergey Vojtovich authored
      Move TABLE::in_use out of LOCK_open.
      
      This is done with assumtion that foreign threads accessing TABLE::in_use
      will only need consistent value _after_ marking table for flush and purging
      unused table instances. In this case TABLE::in_use will always point to a
      valid thread object.
      
      Previously FLUSH TABLES thread may wait for tables flushed subsequently by
      concurrent threads which breaks the above assumption, e.g.:
      open tables: t1 (version= 1)
      thr1 (FLUSH TABLES): refresh_version++
      thr1 (FLUSH TABLES): purge table cache
      open tables: none
      thr2 (SELECT * FROM t1): open tables: t1
      open tables: t1 (version= 2)
      thr2 (FLUSH TABLES): refresh_version++
      thr2 (FLUSH TABLES): purge table cache
      thr1 (FLUSH TABLES): wait for old tables (including t1 with version 2)
      
      It is fixed so that FLUSH TABLES waits only for tables that were open
      heretofore.
      048e9c40
    • Sergey Vojtovich's avatar
      MDEV-5403 - Reduce usage of LOCK_open: tc_count · a25d87e5
      Sergey Vojtovich authored
      Lock-free tc_count.
      a25d87e5
  5. 11 Feb, 2014 9 commits
  6. 10 Feb, 2014 4 commits
  7. 09 Feb, 2014 1 commit
  8. 08 Feb, 2014 3 commits
    • unknown's avatar
      MDEV-5636: Deadlock in RESET MASTER · 07eaf6ea
      unknown authored
      The problem is a deadlock between MYSQL_BIN_LOG::reset_logs() and
      MYSQL_BIN_LOG::mark_xid_done(). The former takes LOCK_log and waits for the
      latter to complete. But the latter also tries to take LOCK_log; this can lead
      to a deadlock.
      
      There was already code that tries to deal with this, with the flag
      reset_master_pending. However, there was still a small opportunity for
      deadlock, when an previous mark_xid_done() is still running when reset_logs()
      is called and is at the precise point where it first releases LOCK_xid_list
      and then re-aquires both LOCK_log and LOCK_xid_list.
      
      Solve by setting reset_master_pending in reset_logs() before taking
      LOCK_log. And also count how many invocations of LOCK_xid_list are in the
      progress of releasing and re-aquiring locks, and in reset_logs() wait for that
      number to drop to zero after setting reset_master_pending and before taking
      LOCK_log.
      07eaf6ea
    • unknown's avatar
      MDEV-4984: Implement MASTER_GTID_WAIT() and @@LAST_GTID. · 76e929a9
      unknown authored
      Rewrite the gtid_waiting::wait_for_gtid() function.
      The code was rubbish (and buggy). Now the logic is
      much clearer.
      
      Also fix a missing slave sync that could cause test failure.
      76e929a9
    • unknown's avatar
      MDEV-4984: Implement MASTER_GTID_WAIT() and @@LAST_GTID. · 3c97d24f
      unknown authored
      Couple of small fixes following buildbot testing.
      3c97d24f
  9. 07 Feb, 2014 2 commits
    • unknown's avatar
      MDEV-4726: Race in mysql-test/suite/rpl/t/rpl_gtid_stop_start.test · 7bb022f3
      unknown authored
      Some GTID test cases were using include/wait_condition.inc with a
      condition like SELECT COUNT(*)=4 FROM t1 to wait for the slave to
      catch up with the master. This causes races and test failures, as the
      changes to the tables become visible at the COMMIT of the SQL thread
      (or even before in case of MyISAM), but the changes to
      @@gtid_slave_pos only become visible a little bit after the COMMIT.
      
      Now that we have MASTER_GTID_WAIT(), just use that to sync up in a
      GTID-friendly way, wrapped in nice include/save_master_gtid.inc and
      include/sync_with_master_gtid.inc scripts.
      7bb022f3
    • unknown's avatar
      MDEV-4984: Implement MASTER_GTID_WAIT() and @@LAST_GTID. · 4e6606ac
      unknown authored
      MASTER_GTID_WAIT() is similar to MASTER_POS_WAIT(), but works with a
      GTID position rather than an old-style filename/offset.
      
      @@LAST_GTID gives the GTID assigned to the last transaction written
      into the binlog.
      
      Together, the two can be used by applications to obtain the GTID of
      an update on the master, and then do a MASTER_GTID_WAIT() for that
      position on any read slave where it is important to get results that
      are caught up with the master at least to the point of the update.
      
      The implementation of MASTER_GTID_WAIT() is implemented in a way
      that tries to minimise the performance impact on the SQL threads,
      even in the presense of many waiters on single GTID positions (as
      from @@LAST_GTID).
      4e6606ac
  10. 06 Feb, 2014 12 commits
  11. 05 Feb, 2014 2 commits