1. 15 Apr, 2015 1 commit
  2. 14 Apr, 2015 3 commits
  3. 13 Apr, 2015 6 commits
    • Alexander Barkov's avatar
    • Kristian Nielsen's avatar
      MDEV-7936: Assertion `!table || table->in_use == _current_thd()' failed on... · ed349270
      Kristian Nielsen authored
      MDEV-7936: Assertion `!table || table->in_use == _current_thd()' failed on parallel replication in optimistic mode
      
      Additional 10.1-specific test case.
      ed349270
    • Kristian Nielsen's avatar
      Merge MDEV-7936 into 10.1 · 2de8db62
      Kristian Nielsen authored
      2de8db62
    • Kristian Nielsen's avatar
      MDEV-7936: Assertion `!table || table->in_use == _current_thd()' failed on... · 60d094ae
      Kristian Nielsen authored
      MDEV-7936: Assertion `!table || table->in_use == _current_thd()' failed on parallel replication in optimistic mode
      
      Make sure that in parallel replication, we execute wait_for_prior_commit()
      before setting table->in_use for a temporary table. Otherwise we can end up
      with two parallel replication worker threads competing with each other for
      use of a temporary table.
      
      Re-factor the use of find_temporary_table() to be able to handle errors
      in the caller (as wait_for_prior_commit() can return error in case of
      deadlock kill).
      60d094ae
    • Kristian Nielsen's avatar
      MDEV-7668: Intermediate master groups CREATE TEMPORARY with INSERT, causing... · c47fe0e9
      Kristian Nielsen authored
      MDEV-7668: Intermediate master groups CREATE TEMPORARY with INSERT, causing parallel replication failure
      
      [This commit cherry-picked to be able to merge MDEV-7936, of which it
      is a pre-requisite, into both 10.0 and 10.1.]
      
      Parallel replication depends on locking (table locks, row locks, etc.) to
      prevent two conflicting transactions from running and committing in parallel.
      But temporary tables are designed to be visible only to one thread, and have
      no such locking.
      
      In the concrete issue, an intermediate master could commit a CREATE TEMPORARY
      TABLE in the same group commit as in INSERT into that table. Thus, a
      lower-level master could attempt to run them in parallel and get an error.
      
      More generally, we need protection from parallel replication trying to run
      transactions in parallel that access a common temporary table.
      
      This patch simply causes use of a temporary table from parallel replication
      to wait for all previous transactions to commit, serialising the replication
      at that point.
      
      (A more fine-grained locking could be added later, possibly. However,
      using temporary tables in statement-based replication is in any case
      normally undesirable; for example a restart of the server will lose
      temporary tables and can break replication).
      
      Note that row-based replication is not affected, as it does not do any
      temporary tables on the slave-side.
      
      This patch also cleans up the locking around protecting the list of
      temporary tables in Relay_log_info. This used to take the
      rli->data_lock at the end of every statement, which is very bad for
      concurrency. With this patch, the lock is not taken unless temporary
      tables (with statement-based binlogging) are in use on the slave.
      c47fe0e9
    • Alexander Barkov's avatar
  4. 12 Apr, 2015 8 commits
  5. 11 Apr, 2015 2 commits
  6. 10 Apr, 2015 16 commits
  7. 09 Apr, 2015 4 commits
    • Sergei Golubchik's avatar
      SET STATEMENT timestamp=xxx .... · eb29a63e
      Sergei Golubchik authored
      fix sys_var->is_default() method (that was using default_val property
      in a global sys_var object to track per-session state):
      * move timestamp to a dedicated Sys_var_timestamp class
        (in fact, rename Sys_var_session_special_double to Sys_var_timestamp)
      * make session_is_default a virtual method with a special implementation
        for timestamps
      * other variables don't have a special behavior for default values
        and can have session_is_default() to be always false.
      eb29a63e
    • Sergei Golubchik's avatar
      0a9052f5
    • Sergei Golubchik's avatar
      Add encryption key id to the API as a distinct concept · 97d5de4c
      Sergei Golubchik authored
      which is separate from the encryption key version
      97d5de4c
    • Sergei Golubchik's avatar
      Merge branch 'bb-10.1-jan-encryption' into bb-10.1-serg · 5dffda3c
      Sergei Golubchik authored
      With changes:
      
      * update tests to pass (new encryption/encryption_key_id syntax).
      * not merged the code that makes engine aware of the encryption mode
        (CRYPT_SCHEME_1_CBC, CRYPT_SCHEME_1_CTR, storing it on disk, etc),
        because now the encryption plugin is handling it.
      * compression+encryption did not work in either branch before the
        merge - and it does not work after the merge. it might be more
        broken after the merge though - some of that code was not merged.
      * page checksumming code was not moved (moving of page checksumming
        from fil_space_encrypt() to fil_space_decrypt was not merged).
      * restored deleted lines in buf_page_get_frame(), otherwise
        innodb_scrub test failed.
      5dffda3c