1. 28 Aug, 2017 3 commits
  2. 25 Aug, 2017 1 commit
    • Marko Mäkelä's avatar
      MDEV-13637 InnoDB change buffer housekeeping can cause redo log overrun and possibly deadlocks · 582545a3
      Marko Mäkelä authored
      The function ibuf_remove_free_page() may be called while the caller
      is holding several mutexes or rw-locks. Because of this, this
      housekeeping loop may cause performance glitches for operations that
      involve tables that are stored in the InnoDB system tablespace.
      Also deadlocks might be possible.
      
      The worst impact of all is that due to the mutexes being held, calls to
      log_free_check() had to be skipped during this housekeeping.
      This means that the cyclic InnoDB redo log may be overwritten.
      If the system crashes during this, it would be unable to recover.
      
      The entry point to the problematic code is ibuf_free_excess_pages().
      It would make sense to call it before acquiring any mutexes or rw-locks,
      in any 'pessimistic' operation that involves the system tablespace.
      
      fseg_create_general(), fseg_alloc_free_page_general(): Do not call
      ibuf_free_excess_pages() while potentially holding some latches.
      
      ibuf_remove_free_page(): Do call log_free_check(), like every operation
      that is about to generate redo log should do.
      
      ibuf_free_excess_pages(): Remove some assertions that are replaced
      by stricter assertions in the log_free_check() that is now called by
      ibuf_remove_free_page().
      
      row_ins_sec_index_entry(), row_undo_ins_remove_sec_low(),
      row_undo_mod_del_mark_or_remove_sec_low(),
      row_undo_mod_del_unmark_sec_and_undo_update(): Call
      ibuf_free_excess_pages() if the operation may involve allocating pages
      and change buffering in the system tablespace.
      582545a3
  3. 24 Aug, 2017 2 commits
  4. 23 Aug, 2017 5 commits
    • Vladislav Vaintroub's avatar
      7aa846e9
    • Vladislav Vaintroub's avatar
    • Vladislav Vaintroub's avatar
      Remove workaround for ancient and already fixed CMake bug in MSI creation. · db51ad1e
      Vladislav Vaintroub authored
      The workaround, an extra cmake calls, somehow makes the
      connect/cmake_install.cmake to lose installation of connect-engine's
      specific jar files.
      db51ad1e
    • Marko Mäkelä's avatar
      MDEV-13606 XA PREPARE transactions should survive innodb_force_recovery=1 or 2 · b8b3ba63
      Marko Mäkelä authored
      When MySQL 5.0.3 introduced InnoDB support for two-phase commit,
      it also introduced the questionable logic to roll back XA PREPARE
      transactions on startup when innodb_force_recovery is 1 or 2.
      
      Remove this logic in order to avoid unwanted side effects when
      innodb_force_recovery is being set for other reasons. That is,
      XA PREPARE transactions will always remain in that state until
      InnoDB receives an explicit XA ROLLBACK or XA COMMIT request
      from the upper layer.
      
      At the time the logic was introduced in MySQL 5.0.3, there already
      was a startup parameter that is the preferred way of achieving
      the behaviour: --tc-heuristic-recover=ROLLBACK.
      b8b3ba63
    • Marko Mäkelä's avatar
      MDEV-13167 InnoDB key rotation is not skipping unused pages · 97f9d3c0
      Marko Mäkelä authored
      In key rotation, we must initialize unallocated but previously
      initialized pages, so that if encryption is enabled on a table,
      all clear-text data for the page will eventually be overwritten.
      But we should not rotate keys on pages that were never allocated
      after the data file was created.
      
      According to the latching order rules, after acquiring the
      tablespace latch, no page latches of previously allocated user pages
      may be acquired. So, key rotation should check the page allocation
      status after acquiring the page latch, not before. But, the latching
      order rules also prohibit accessing pages that were not allocated first,
      and then acquiring the tablespace latch. Such behaviour would indeed
      result in a deadlock when running the following tests:
      encryption.innodb_encryption-page-compression
      encryption.innodb-checksum-algorithm
      
      Because the key rotation is accessing potentially unallocated pages, it
      cannot reliably check if these pages were allocated. It can only check
      the page header. If the page number is zero, we can assume that the
      page is unallocated.
      
      fil_crypt_rotate_page(): Detect uninitialized pages by FIL_PAGE_OFFSET.
      Page 0 is never encrypted, and on other pages that are initialized,
      FIL_PAGE_OFFSET must contain the page number.
      
      fil_crypt_is_page_uninitialized(): Remove. It suffices to check the
      page number field in fil_crypt_rotate_page().
      97f9d3c0
  5. 22 Aug, 2017 1 commit
  6. 21 Aug, 2017 1 commit
  7. 18 Aug, 2017 1 commit
    • Jan Lindström's avatar
      MDEV-8960: Can't refer the same column twice in one ALTER TABLE · ce6c0e58
      Jan Lindström authored
      Problem was that if column was created in alter table when
      it was refered again it was not tried to find from list
      of current columns.
      
      mysql_prepare_alter_table:
        There is two cases
          (1) If alter table adds a new column and then later alter
              changes the field definition, there was no check from
      	list of new columns, instead an incorrect error was given.
          (2) If alter table adds a new column and then later alter
              changes the default, there was no check from list of
      	new columns, instead an incorrect error was given.
      ce6c0e58
  8. 17 Aug, 2017 2 commits
  9. 15 Aug, 2017 3 commits
  10. 14 Aug, 2017 1 commit
  11. 13 Aug, 2017 2 commits
  12. 10 Aug, 2017 1 commit
  13. 09 Aug, 2017 3 commits
  14. 08 Aug, 2017 7 commits
  15. 07 Aug, 2017 4 commits
    • Daniel Bartholomew's avatar
      bump the VERSION · ef2e51c3
      Daniel Bartholomew authored
      ef2e51c3
    • Jan Lindström's avatar
      MDEV-13443: Port innochecksum tests from 10.2 innodb_zip suite to 10.1 · 2ef7a5a1
      Jan Lindström authored
      This is basically port of WL6045:Improve Innochecksum with some
      code refactoring on innochecksum.
      
      Added page0size.h include from 10.2 to make 10.1 vrs 10.2 innochecksum
      as identical as possible.
      
      Added page 0 checksum checking and if that fails whole test fails.
      2ef7a5a1
    • Monty's avatar
      Fixed compiler warnings · 19f2b3d0
      Monty authored
      19f2b3d0
    • Monty's avatar
      MDEV-13179 main.errors fails with wrong errno · 74543698
      Monty authored
      The problem was that the introduction of max-thread-mem-used can cause
      an allocation error very early, even before mysql_parse() is called.
      As mysql_parse() calls thd->reset_for_next_command(), which called
      clear_error(), the error number was lost.
      
      Fixed by adding an option to have unique messages for each KILL
      signal and change max-thread-mem-used to use this new feature.
      This removes a lot of problems with the original approach, where
      one could get errors signaled silenty almost any time.
      
      ixed by moving clear_error() from reset_for_next_command() to
      do_command(), before any memory allocation for the thread.
      
      Related changes:
      - reset_for_next_command() now have an optional parameter if we should
        call clear_error() or not. By default it's called, but not anymore from
        dispatch_command() which was the original problem.
      - Added optional paramater to clear_error() to force calling of
        reset_diagnostics_area(). Before clear_error() only called
        reset_diagnostics_area() if there was no error, so we normally
        called reset_diagnostics_area() twice.
      - This change removed several duplicated calls to clear_error()
        when starting a query.
      - Reset max_mem_used on COM_QUIT, to protect against kill during
        quit.
      - Use fatal_error() instead of setting is_fatal_error (cleanup)
      - Set fatal_error if max_thead_mem_used is signaled.
        (Same logic we use for other places where we are out of resources)
      74543698
  16. 05 Aug, 2017 1 commit
  17. 04 Aug, 2017 2 commits