1. 20 Jul, 2017 1 commit
  2. 15 Jul, 2017 1 commit
  3. 14 Jul, 2017 1 commit
  4. 11 Jul, 2017 1 commit
  5. 06 Jul, 2017 4 commits
  6. 05 Jul, 2017 1 commit
  7. 04 Jul, 2017 1 commit
  8. 03 Jul, 2017 6 commits
  9. 02 Jul, 2017 2 commits
    • Andrei Elkin's avatar
      Fix for MDEV-9670 server_id mysteriously set to 0 · 946a07e8
      Andrei Elkin authored
      Problem was that in a circular replication setup the master remembers
      position to events it has generated itself when reading from a slave.
      If there are no new events in the queue from the slave, a
      Gtid_list_log_event is generated to remember the last skipped event.
      The problem happens if there is a network delay and we generate a
      Gtid_list_log_event in the middle of the transaction, in which case there
      will be an implicit comment and a new transaction with serverid=0 will be
      logged.
      
      The fix was to not generate any Gtid_list_log_events in the middle of a
      transaction.
      946a07e8
    • Monty's avatar
      Fix for MDEV-13191. Assert for !is_set() when doing LOAD DATA · 46d6f74c
      Monty authored
      This could happen when the client connection dies while sending a progress
      report packet.
      Fixed by not raising any errors when sending progress packets.
      46d6f74c
  10. 30 Jun, 2017 1 commit
  11. 29 Jun, 2017 3 commits
  12. 28 Jun, 2017 1 commit
  13. 27 Jun, 2017 2 commits
  14. 20 Jun, 2017 1 commit
  15. 19 Jun, 2017 3 commits
    • Sergei Golubchik's avatar
    • Marko Mäkelä's avatar
      MDEV-12975 InnoDB redo log minimum size check uses detected file size instead... · 5e4f4ec8
      Marko Mäkelä authored
      MDEV-12975 InnoDB redo log minimum size check uses detected file size instead of requested innodb_log_file_size
      
      log_calc_max_ages(): Use the requested size in the check, instead of
      the detected redo log size. The redo log will be resized at startup
      if it differs from what has been requested.
      5e4f4ec8
    • Alexander Barkov's avatar
      MDEV-10306 Wrong results with combination of CONCAT, SUBSTR and CONVERT in subquery · 3a37afec
      Alexander Barkov authored
      The bug happens because of a combination of unfortunate circumstances:
      
      1. Arguments args[0] and args[2] of Item_func_concat point recursively
      (through Item_direct_view_ref's) to the same Item_func_conv_charset.
      Both args[0]->args[0]->ref[0] and args[2]->args[0]->ref[0] refer to
      this Item_func_conv_charset.
      
      2. When Item_func_concat::args[0]->val_str() is called,
      Item_func_conv_charset::val_str() writes its result to
      Item_func_conc_charset::tmp_value.
      
      3. Then, for optimization purposes (to avoid copying),
      Item_func_substr::val_str() initializes Item_func_substr::tmp_value
      to point to the buffer fragment owned by Item_func_conv_charset::tmp_value
      Item_func_substr::tmp_value is returned as a result of
      Item_func_concat::args[0]->val_str().
      
      4. Due to optimization to avoid memory reallocs,
      Item_func_concat::val_str() remembers the result of args[0]->val_str()
      in "res" and further uses "res" to collect the return value.
      
      5. When Item_func_concat::args[2]->val_str() is called,
      Item_func_conv_charset::tmp_value gets overwritten (see #1),
      which effectively overwrites args[0]'s Item_func_substr::tmp_value (see #3),
      which effectively overwrites "res" (see #4).
      
      This patch does the following:
      
      a. Changes Item_func_conv_charset::val_str(String *str) to use
         tmp_value and str the other way around. After this change tmp_value
         is used to store a temporary result, while str is used to return the value.
         The fixes the second problem (without SUBSTR):
           SELECT CONCAT(t2,'-',t2) c2
             FROM (SELECT CONVERT(t USING latin1) t2 FROM t1) sub;
         As Item_func_concat::val_str() supplies two different buffers when calling
         args[0]->val_str() and args[2]->val_str(), in the new reduction the result
         created during args[0]->val_str() does not get overwritten by
         args[2]->val_str().
      
      b. Fixing the same problem in val_str() for similar classes
      
         Item_func_to_base64
         Item_func_from_base64
         Item_func_weight_string
         Item_func_hex
         Item_func_unhex
         Item_func_quote
         Item_func_compress
         Item_func_uncompress
         Item_func_des_encrypt
         Item_func_des_decrypt
         Item_func_conv_charset
         Item_func_reverse
         Item_func_soundex
         Item_func_aes_encrypt
         Item_func_aes_decrypt
         Item_func_buffer
      
      c. Fixing Item_func::val_str_from_val_str_ascii() the same way.
         Now Item_str_ascii_func::ascii_buff is used for temporary value,
         while the parameter passed to val_str() is used to return the result.
         This fixes the same problem when conversion (from ASCII to e.g. UCS2)
         takes place. See the ctype_ucs.test for example queries that returned
         wrong results before the fix.
      
      d. Some Item_func descendand classes had temporary String buffers
         (tmp_value and tmp_str), but did not really use them.
         Removing these temporary buffers from:
      
         Item_func_decode_histogram
         Item_func_format
         Item_func_binlog_gtid_pos
         Item_func_spatial_collection:
      
      e. Removing Item_func_buffer::tmp_value, because it's not used any more.
      
      f. Renaming Item_func_[un]compress::buffer to "tmp_value",
         for consistency with other classes.
      
      Note, this patch does not fix the following classes
      (although they have a similar problem):
      
         Item_str_conv
         Item_func_make_set
         Item_char_typecast
      
      They have a complex implementations and simple swapping between "tmp_value"
      and "str" won't work. These classes will be fixed separately.
      3a37afec
  16. 18 Jun, 2017 3 commits
  17. 15 Jun, 2017 3 commits
    • Vicențiu Ciorbaru's avatar
      MDEV-12666: CURRENT_ROLE() and DATABASE() does not work in a view · f0ad9340
      Vicențiu Ciorbaru authored
      The problem lies in how CURRENT_ROLE is defined. The
      Item_func_current_role inherits from Item_func_sysconst, which defines
      a safe_charset_converter to be a const_charset_converter.
      
      During view creation, if there is no role previously set, the current_role()
      function returns NULL.
      
      This is captured on item instantiation and the
      const_charset_converter call subsequently returns an Item_null.
      In turn, the function is replaced with Item_null and the view is
      then created with an Item_null instead of Item_func_current_role.
      
      Without this patch, the first SHOW CREATE VIEW from the testcase would
      have a where clause of WHERE role_name = NULL, while the second SHOW
      CREATE VIEW would show a correctly created view.
      
      The same applies for the DATABASE function, as it can change as well.
      
      There is an additional problem with CURRENT_ROLE() when used in a
      prepared statement. During prepared statement creation we used to set
      the string_value of the function to the current role as well as the
      null_value flag. During execution, if CURRENT_ROLE was not null, the
      null_value flag was never set to not-null during fix_fields.
      
      Item_func_current_user however can never be NULL so it did not show this
      problem in a view before. At the same time, the CURRENT_USER() can not
      be changed between prepared statement execution and creation so the
      implementation where the value is stored during fix_fields is
      sufficient.
      
      Note also that DATABASE() function behaves differently during prepared
      statements. See bug 25843 for details or commit
      7e0ad09e
      f0ad9340
    • Vicențiu Ciorbaru's avatar
      MDEV-10463: Granted as a whole to roles, databases are not show in SHOW DATABASES · 34da3be8
      Vicențiu Ciorbaru authored
      The problem lies in not checking role privileges as well during SHOW
      DATABASES command. This problem is also apparent for SHOW CREATE
      DATABASE command.
      
      Other SHOW COMMANDS make use of check_access, which in turn makes use of
      acl_get for both priv_user and priv_role parts, which allows them to
      function correctly.
      34da3be8
    • =Ian Gilfillan's avatar
      Update MariaDB Foundation sponsors · 2579b252
      =Ian Gilfillan authored
      2579b252
  18. 14 Jun, 2017 4 commits
  19. 13 Jun, 2017 1 commit