1. 21 Dec, 2017 4 commits
  2. 20 Dec, 2017 9 commits
  3. 19 Dec, 2017 10 commits
    • sjaakola's avatar
      MW-416 DDL replication moved after acl checking · 64e1dda0
      sjaakola authored
      galera_events test shows a regression with the original fix for MW-416
      Reason was that Events::drop_event() can be called also from inside event
      execution, and there we have a speacial treatment for event, which executes
      "DROP EVENT" statement, and runs TOI replication inside the event processing body.
      This resulted in executing WSREP_TO_ISOLATION two times for such DROP EVENT statement.
      Fix is to call WSREP_TO_ISOLATION_BEGIN only in Events::drop_event()
      64e1dda0
    • sjaakola's avatar
      MW-416 · 1a8da003
      sjaakola authored
      Changed return code for replicatio error to TRUE.
      This is aligned with native mysql convention to return TRUE (defined to 1) or FALSE (defined to 0) from a bool function.
      This is wrong, but follows the mysql conventiosn, at least...
      1a8da003
    • Simon J Mudd's avatar
    • Sergey Vojtovich's avatar
      MDEV-14265 - RPMLint warning: shared-lib-calls-exit · 2cd31691
      Sergey Vojtovich authored
      find_type_or_exit() client helper did exit(1) on error, exit(1) moved to
      clients.
      
      mysql_read_default_options() did exit(1) on error, error is passed through and
      handled now.
      
      my_str_malloc_default() did exit(1) on error, replaced my_str_ allocator
      functions with normal my_malloc()/my_realloc()/my_free().
      
      sql_connect.cc did many exit(1) on hash initialisation failure. Removed error
      check since my_hash_init() never fails.
      
      my_malloc() did exit(1) on error. Replaced with abort().
      
      my_load_defaults() did exit(1) on error, replaced with return 2.
      
      my_load_defaults() still does exit(0) when invoked with --print-defaults.
      2cd31691
    • Jan Lindström's avatar
      DEV-14701: install_db shows corruption for rest encryption with innodb_data_file_path=ibdata1:3M · ed7e4b68
      Jan Lindström authored
      Problem was that crypt_data->min_key_version is not a reliable way
      to detect is tablespace encrypted and could lead that in first page
      of the second (page 192 and similarly for other files if more configured)
      system tablespace file used key_version is replaced with zero leading
      a corruption as in next startup page is though to be corrupted.
      Note that crypt_data->min_key_version is updated only after all
      pages from tablespace have been processed (i.e. key rotation is done)
      and flushed.
      
      fil_write_flushed_lsn
              Use crypt_data->should_encrypt() instead.
      ed7e4b68
    • Jan Lindström's avatar
      Fix galera.view test case crash. · 252e690c
      Jan Lindström authored
      WSREP_TO_ISOLATION_BEGIN() call must be after view name is back
      on tables list.
      252e690c
    • Vicențiu Ciorbaru's avatar
      MDEV-12366: FLUSH PRIVILEGES can break hierarchy of roles · be758322
      Vicențiu Ciorbaru authored
      Whenever we call merge_role_privileges on a role, we make use of
      the role->counter variable to check if all it's children have had their
      privileges merged. Only if all children have had their privileges merged,
      do we update the privileges on parent. This is done to prevent extra work.
      The same idea is employed during flush privileges. You only begin merging
      from "leaf" roles. The recursive calls will merge their parents at some point.
      A problem arises when we try to "re-merge" a parent. Take the following graph:
      
      {noformat}
           A (0)  ----  C (2) ---- D (2)  ---- USER
                       /          /
           B (0)  ----/          /
                                /
           E (0) --------------/
      {noformat}
      
      In parentheses we have the "counter" value right before we start to iterate
      through the roles hash and propagate values. It represents the number of roles
      granted to the current role. The order in which we iterate through the roles
      hash is alphabetical.
      
      * First merge A, which leads to decreasing the counter for C to 1. Since C is
      not 0, we don't proceed with merging into C.
      
      * Second we merge B, which leads to decreasing the counter for C to 0. Now
      we proceed with merging into C. This leads to reducing the counter for D to 1
      as part of C merge process.
      
      * Third as we iterate through the hash, we see that C has counter 0, thus we
      start the merge process *again*. This leads to reducing the counter for
      D to 0! We then attempt to merge D.
      
      * Fourth we start merging E. When E sees D as it's parent (according to the code)
      it attempts to reduce D's counter, which leads to overflow. Now D's counter is
      a very large number, thus E's privileges are not forwarded to D yet.
      
      To correct this behavior we must make sure to only start merging from initial
      leaf nodes.
      be758322
    • Vicențiu Ciorbaru's avatar
      MDEV-13655: Set role does not properly grant privileges. · 2fced9e7
      Vicențiu Ciorbaru authored
      When granting a role to another role, DB privileges get propagated. If
      the grantee had no previous DB privileges, an extra ACL_DB entry is created to
      house those "indirectly received" privileges. If, afterwards, DB
      privileges are granted to the grantee directly, we must make sure to not
      create a duplicate ACL_DB entry.
      2fced9e7
    • Daniel Black's avatar
    • Daniel Black's avatar
      64f1fab0
  4. 18 Dec, 2017 10 commits
  5. 16 Dec, 2017 1 commit
  6. 14 Dec, 2017 1 commit
  7. 13 Dec, 2017 5 commits