1. 01 Jun, 2015 4 commits
  2. 31 May, 2015 2 commits
  3. 30 May, 2015 5 commits
  4. 29 May, 2015 4 commits
  5. 28 May, 2015 3 commits
  6. 27 May, 2015 6 commits
  7. 26 May, 2015 5 commits
  8. 25 May, 2015 1 commit
  9. 21 May, 2015 3 commits
  10. 20 May, 2015 5 commits
    • Jan Lindström's avatar
      MDEV-8182: Failing assertion: 1 == UT_LIST_GET_LEN(space->chain) · 925b6412
      Jan Lindström authored
      Analysis: At fil_spage_get_space there is small change that space
      is found from tablespace list but we have not yet created node
      for it (and added it to space->chain) and as we hold fil_system
      mutex here fil_node_create can't continue.
      
      Fixed by allowing UT_LIST_GET_LEN(space->chain) == 0|| 1 and
      introducint two new functions that access filespace list
      and before returning space check that node is also created.
      925b6412
    • Jan Lindström's avatar
      MDEV-8173: InnoDB; Failing assertion: crypt_data->type == 1 · 3e55ef26
      Jan Lindström authored
      Make sure that when we publish the crypt_data we access the
      memory cache of the tablespace crypt_data. Make sure that
      crypt_data is stored whenever it is really needed.
      
      All this is not yet enough in my opinion because:
      
      sql/encryption.cc has DBUG_ASSERT(scheme->type == 1) i.e.
      crypt_data->type == CRYPT_SCHEME_1
      
      However, for InnoDB point of view we have global crypt_data
      for every tablespace. When we change variables on crypt_data
      we take mutex. However, when we use crypt_data for
      encryption/decryption we use pointer to this global
      structure and no mutex to protect against changes on
      crypt_data.
      
      Tablespace encryption starts in fil_crypt_start_encrypting_space
      from crypt_data that has crypt_data->type = CRYPT_SCHEME_UNENCRYPTED
      and later we write page 0 CRYPT_SCHEME_1 and finally whe publish
      that to memory cache.
      3e55ef26
    • Oleksandr Byelkin's avatar
      MDEV-7921: main.sp_sync fails in buildbot with valgrind · 44cd6f22
      Oleksandr Byelkin authored
      Part 2: detauch service thread.
      44cd6f22
    • Oleksandr Byelkin's avatar
      MDEV-7921: main.sp_sync fails in buildbot with valgrind · c1fb91ef
      Oleksandr Byelkin authored
      Part 1: first 2 cases of valgrind complain. context_analysis_only can be used on non-started LEX (opening tables)
      
      obviouse fixes in DBUG and is_lex_started assignment.
      c1fb91ef
    • Jan Lindström's avatar
  11. 19 May, 2015 2 commits