1. 18 Mar, 2016 7 commits
    • Alexander Barkov's avatar
      MDEV-9653 Assertion `length || !scale' failed in uint... · b25373be
      Alexander Barkov authored
      MDEV-9653 Assertion `length || !scale' failed in uint my_decimal_length_to_precision(uint, uint, bool)
      MDEV-9752 Wrong data type for COALEASCE(?,1) in prepared statements
      b25373be
    • Sergey Vojtovich's avatar
      Fixed plugins.cracklib_password_check failure · 546e9139
      Sergey Vojtovich authored
      In RHEL7/RHEL7.1 libcrack behavior seem to have been modified so that
      "foobar" password is considered bad (due to descending "ba") earlier than
      expected. For details google for cracklib-2.9.0-simplistic.patch.
      
      Adjusted affected passwords not to have descending and ascending sequences.
      546e9139
    • Akira Higuchi's avatar
    • Akira Higuchi's avatar
      fix a memory leak in handlersocket · 4f0fc0f9
      Akira Higuchi authored
      4f0fc0f9
    • Jan Lindström's avatar
    • Sergey Vojtovich's avatar
      4aac51db
    • Jan Lindström's avatar
      MDEV-9422: Checksum errors on restart when killing busy instance that uses encrypted XtraDB tables · f448a800
      Jan Lindström authored
      Analysis:
      
      -- InnoDB has n (>0) redo-log files.
      -- In the first page of redo-log there is 2 checkpoint records on fixed location (checkpoint is not encrypted)
      -- On every checkpoint record there is up to 5 crypt_keys containing the keys used for encryption/decryption
      -- On crash recovery we read all checkpoints on every file
      -- Recovery starts by reading from the latest checkpoint forward
      -- Problem is that latest checkpoint might not always contain the key we need to decrypt all the
         redo-log blocks (see MDEV-9422 for one example)
      -- Furthermore, there is no way to identify is the log block corrupted or encrypted
      
      For example checkpoint can contain following keys :
      
      write chk: 4 [ chk key ]: [ 5 1 ] [ 4 1 ] [ 3 1 ] [ 2 1 ] [ 1 1 ]
      
      so over time we could have a checkpoint
      
      write chk: 13 [ chk key ]: [ 14 1 ] [ 13 1 ] [ 12 1 ] [ 11 1 ] [ 10 1 ]
      
      killall -9 mysqld causes crash recovery and on crash recovery we read as
      many checkpoints as there is log files, e.g.
      
      read [ chk key ]: [ 13 1 ] [ 12 1 ] [ 11 1 ] [ 10 1 ] [ 9 1 ]
      read [ chk key ]: [ 14 1 ] [ 13 1 ] [ 12 1 ] [ 11 1 ] [ 10 1 ] [ 9 1 ]
      
      This is problematic, as we could still scan log blocks e.g. from checkpoint 4 and we do
      not know anymore the correct key.
      
      CRYPT INFO: for checkpoint 14 search 4
      CRYPT INFO: for checkpoint 13 search 4
      CRYPT INFO: for checkpoint 12 search 4
      CRYPT INFO: for checkpoint 11 search 4
      CRYPT INFO: for checkpoint 10 search 4
      CRYPT INFO: for checkpoint 9 search 4 (NOTE: NOT FOUND)
      
      For every checkpoint, code generated a new encrypted key based on key
      from encryption plugin and random numbers. Only random numbers are
      stored on checkpoint.
      
      Fix: Generate only one key for every log file. If checkpoint contains only
      one key, use that key to encrypt/decrypt all log blocks. If checkpoint
      contains more than one key (this is case for databases created
      using MariaDB server version 10.1.0 - 10.1.12 if log encryption was
      used). If looked checkpoint_no is found from keys on checkpoint we use
      that key to decrypt the log block. For encryption we use always the
      first key. If the looked checkpoint_no is not found from keys on checkpoint
      we use the first key.
      
      Modified code also so that if log is not encrypted, we do not generate
      any empty keys. If we have a log block and no keys is found from
      checkpoint we assume that log block is unencrypted. Log corruption or
      missing keys is found by comparing log block checksums. If we have
      a keys but current log block checksum is correct we again assume
      log block to be unencrypted. This is because current implementation
      stores checksum only before encryption and new checksum after
      encryption but before disk write is not stored anywhere.
      f448a800
  2. 17 Mar, 2016 1 commit
  3. 16 Mar, 2016 1 commit
  4. 15 Mar, 2016 1 commit
  5. 13 Mar, 2016 3 commits
  6. 12 Mar, 2016 1 commit
    • Jan Lindström's avatar
      MDEV-9549: Trying to decrypt a not encrypted page · f341d944
      Jan Lindström authored
      Make sure that on decrypt we do not try to reference
      NULL pointer and if page contains undefined
      FIL_PAGE_FILE_FLUSH_LSN field on when page is not
      the first page or page is not in system tablespace,
      clear it.
      f341d944
  7. 08 Mar, 2016 2 commits
  8. 05 Mar, 2016 5 commits
  9. 01 Mar, 2016 1 commit
  10. 26 Feb, 2016 1 commit
  11. 25 Feb, 2016 1 commit
  12. 24 Feb, 2016 11 commits
    • Sergei Petrunia's avatar
      MDEV-8988: Apparently valid SQL query gives wrong result (nested WHERE) · b05158cc
      Sergei Petrunia authored
      - "Early NULLs filtering" optimization used to "peel off" Item_ref and
        Item_direct_ref wrappers from an outside column reference before
        adding "outer_table_col IS NOT NULL" into JOIN::outer_ref_cond.
      - When this happened in a subquery that was evaluated in a post-GROUP-BY
        context, attempt to evaluate JOIN::outer_ref_cond would fetch an
        incorrect value of outer_table_col.
      b05158cc
    • Sergei Golubchik's avatar
      Merge branch 'bb-10.1-serg' into 10.1 · d044507d
      Sergei Golubchik authored
      10.0 merge
      10.0-galera merge
      connect/10.1 merge
      d044507d
    • Sergei Golubchik's avatar
      fix test results after the merge · 5a4ec8e6
      Sergei Golubchik authored
      5a4ec8e6
    • Alexander Barkov's avatar
      MDEV-7231 Field ROUTINE_DEFINITION in INFORMATION_SCHEMA.`ROUTINES` · ff2d92b1
      Alexander Barkov authored
      contains broken procedure body when used shielding quotes inside.
      ff2d92b1
    • Nirbhay Choubey's avatar
      cceec785
    • Krunal Bauskar's avatar
      - PXC#480: xtrabackup-v2 SST fails with multiple log_bin directives in my.cnf · f67d6fcc
      Krunal Bauskar authored
        If any given variable the xtrabackup-v2 sst script looks for is specified
        multiple times in cnf file then it tend to pick both of them causing
        some of the follow-up command to fail.
      
        Avoid this programatic mistake by honoring only the last variable assigned
        setting as done by mysqld too.
      
        Check https://bugs.launchpad.net/percona-xtradb-cluster/+bug/1362830
      f67d6fcc
    • Krunal Bauskar's avatar
      - PXC#460: wsrep_sst_auth don't work in Percona-XtraDB-Cluster-56-5.6.25-25.12.1.el7 · 0cf66e49
      Krunal Bauskar authored
      Semantics:
      ---------
      
      * Generally end-user will create a separate user with needed
      privileges for
          performing DONOR action.
      * This user credentials are specified using wsrep_sst_auth.
      
      * Along with this user there could be other user(s) created on the
      server
          that sysadmin may use for normal or other operations
      * Credentials for these user(s) can be specified in same
      cluster/server
          cnf file as part of [client] section
      
      When cluster act as DONOR and if wsrep_sst_auth is provided then it
      should
      strictly use it for performing SST based action.
      
      What if end-user has same credentials for performing both SST action
      and
      normal admin work ?
      * Then end-user can simply specify these credentials as part of
      [client]
          section in cnf file and skip providing wsrep_sst_auth.
      
      Issue:
      -----
      
      MySQL client user/password parsing preference order is as follows:
      * command line (through --user/--password)
      * cnf file
      * MYSQL_PWD enviornment variable.
      
      Recent change tried passing sst user password through MYSQL_PWD
      (and user though --user command line param as before).
      
      On the system where-in admin had another user for performing non-SST
      actions,
      credentials for such user were present in cnf file under [client]
      section.
      
      Due to mysql client preference order, SST user name was used (as it
      was
      passed through command line) but password of other user (meant for
      non-SST)
      action was being used as it was passed through cnf file.
      
      Password passed through MYSQL_PWD was completely ignored causing
      user-name/password mismatch.
      
      Solution:
      ---------
      
      * If user has specified credentials for SST then pass them through
      command
          line so that they are used in priority.
      
      (There could be security concern on passing things through command
      line but
         when I tried passing user-name and password through command line to
      mysql
         client and then did ps I saw this
         ./bin/mysql --user=sstuser --password=x xxxxxxxx -S /tmp/n1.sock
      so seems like password is not shown)
      0cf66e49
    • Nirbhay Choubey's avatar
      Update WSREP_PATCH_REVNO. · 0fd9d5a6
      Nirbhay Choubey authored
      0fd9d5a6
    • Nirbhay Choubey's avatar
      1b0d811d
    • Nirbhay Choubey's avatar
      0d58323e
    • Nirbhay Choubey's avatar
      Fix for test failures. · 276d65b3
      Nirbhay Choubey authored
      276d65b3
  13. 23 Feb, 2016 5 commits