1. 12 Dec, 2018 2 commits
    • Sergei Golubchik's avatar
      debian install/upgrade fixes · 54150029
      Sergei Golubchik authored
      1. don't run full mysql_upgrade on every server restart,
         use --version-check to do it only once
      
      2. fix syslog tag name in the postinst script, don't pretend
         mysqld_safe generated all these messages. Auto-detect the version
         to simplify maintenance
      54150029
    • Marko Mäkelä's avatar
      Merge 10.0 into 10.1 · f77f8f6d
      Marko Mäkelä authored
      f77f8f6d
  2. 11 Dec, 2018 1 commit
  3. 07 Dec, 2018 3 commits
  4. 06 Dec, 2018 5 commits
  5. 05 Dec, 2018 1 commit
  6. 26 Nov, 2018 3 commits
    • Jan Lindström's avatar
      328d7779
    • Jan Lindström's avatar
      MDEV-17804: Galera tests cause mysql_socket.h:738: inline_mysql_socket_send:... · 1037edcb
      Jan Lindström authored
      MDEV-17804: Galera tests cause mysql_socket.h:738: inline_mysql_socket_send: Assertion `mysql_socket.fd != -1' failed.
      
      Do not do end of statement logic if thd is already killed as
      socket is already closed.
      1037edcb
    • Jan Lindström's avatar
      MDEV-17801: Galera test failure on galera_var_reject_queries · 244cc35e
      Jan Lindström authored
      Problem was that controlling connection i.e. connection that
      executed the query SET GLOBAL wsrep_reject_queries = ALL_KILL;
      was also killed but server would try to send result from that
      query to controlling connection resulting a assertion
      mysqld: /home/jan/mysql/10.2-sst/include/mysql/psi/mysql_socket.h:738: inline_mysql_socket_send: Assertion `mysql_socket.fd != -1' failed.
      as socket was closed when controlling connection was closed.
      
      wsrep_close_client_connections()
      	Do not close controlling connection and instead of
      	wsrep_close_thread() we do now soft kill by THD::awake
      
      wsrep_reject_queries_update()
      	Call wsrep_close_client_connections using current thd.
      244cc35e
  7. 21 Nov, 2018 1 commit
  8. 20 Nov, 2018 2 commits
  9. 19 Nov, 2018 9 commits
  10. 17 Nov, 2018 1 commit
  11. 16 Nov, 2018 1 commit
  12. 15 Nov, 2018 4 commits
  13. 14 Nov, 2018 2 commits
  14. 07 Nov, 2018 3 commits
  15. 06 Nov, 2018 2 commits
    • Anel Husakovic's avatar
    • Jan Lindström's avatar
      MDEV-17230: encryption_key_id from alter is ignored by encryption threads · ef400185
      Jan Lindström authored
      Background: Used encryption key_id is stored to encryption metadata
      i.e. crypt_data that is stored on page 0 of the tablespace of the
      table. crypt_data is created only if implicit encryption/not encryption
      is requested i.e. ENCRYPTED=[YES|NO] table option is used
      fil_create_new_single_table_tablespace on fil0fil.cc.
      
      Later if encryption is enabled all tables that use default encryption
      mode (i.e. no encryption table option is set) are encrypted with
      default encryption key_id that is 1. See fil_crypt_start_encrypting_space on
      fil0crypt.cc.
      
      ha_innobase::check_table_options()
      	If default encryption is used and encryption is disabled, you may
              not use nondefault encryption_key_id as it is not stored anywhere.
      ef400185