1. 17 Oct, 2016 6 commits
    • Sergey Vojtovich's avatar
      MDEV-7148 - Recurring: InnoDB: Failing assertion: !lock->recursive · 8303aded
      Sergey Vojtovich authored
      On PPC64 high-loaded server may crash due to assertion failure in InnoDB
      rwlocks code.
      
      This happened because load order between "recursive" and "writer_thread"
      wasn't properly enforced.
      8303aded
    • Sergey Vojtovich's avatar
      MDEV-10813 - Clean-up InnoDB atomics, memory barriers and mutexes · 2b47f8ff
      Sergey Vojtovich authored
      Clean-up periodic mutex/rwlock waiters wake up. This was a hack needed to
      workaround broken mutexes/rwlocks implementation. We must have sane
      implementations now and don't need these anymore: release thread is
      guaranteed to wake up waiters.
      
      Removed redundant ifdef that has equivalent code in both branches.
      
      Removed os0atomic.h and os0atomic.ic: not used anymore.
      
      Clean-up unused cmake checks.
      2b47f8ff
    • Sergey Vojtovich's avatar
      MDEV-10813 - Clean-up InnoDB atomics, memory barriers and mutexes · 5608a737
      Sergey Vojtovich authored
      No point to issue RELEASE memory barrier in os_thread_create_func(): thread
      creation is full memory barrier.
      
      No point to issue os_wmb in rw_lock_set_waiter_flag() and
      rw_lock_reset_waiter_flag(): this is deadcode and it is unlikely operational
      anyway. If atomic builtins are unavailable - memory barriers are most certainly
      unavailable too.
      
      RELEASE memory barrier is definitely abused in buf_pool_withdraw_blocks(): most
      probably it was supposed to commit volatile variable update, which is not what
      memory barriers actually do. To operate properly it needs corresponding ACQUIRE
      barrier without an associated atomic operation anyway.
      
      ACQUIRE memory barrier is definitely abused in log_write_up_to(): most probably
      it was supposed to synchronize dirty read of log_sys->write_lsn. To operate
      properly it needs corresponding RELEASE barrier without an associated atomic
      operation anyway.
      
      Removed a bunch of ACQUIRE memory barriers from InnoDB rwlocks. They're
      meaningless without corresponding RELEASE memory barriers.
      
      Valid usage example of memory barriers without an associated atomic operation:
      http://en.cppreference.com/w/cpp/atomic/atomic_thread_fence
      5608a737
    • Sergey Vojtovich's avatar
      MDEV-10813 - Clean-up InnoDB atomics, memory barriers and mutexes · f4d885c4
      Sergey Vojtovich authored
      Replaced InnoDB atomic operations with server atomic operations.
      
      Moved INNODB_RW_LOCKS_USE_ATOMICS - it is always defined (code won't compile
      otherwise).
      
      NOTE: InnoDB uses thread identifiers as a target for atomic operations.
      Thread identifiers should be considered opaque: any attempt to use a
      thread ID other than in pthreads calls is nonportable and can lead to
      unspecified results.
      f4d885c4
    • Sergey Vojtovich's avatar
      MDEV-10813 - Clean-up InnoDB atomics, memory barriers and mutexes · d055e28f
      Sergey Vojtovich authored
      Simplified InnoDB mutex implementations, corrected memory barriers usage, use
      server atomic builtins.
      d055e28f
    • Kristian Nielsen's avatar
      Move InnoDB/XtraDB to async deadlock kill for parallel replication. · cc49f009
      Kristian Nielsen authored
      In 10.2, use the thd_rpl_deadlock_check() API. This way, all the
      locking hacks around thd_report_wait_for() can be removed. Now
      parallel replication deadlock kill happens asynchroneously, from the
      slave background thread.
      
      In InnoDB, remove also the buffering of wait reports, to simplify the
      code, as this is no longer needed when the locking issues are gone.
      
      In XtraDB, the buffering is kept for now. This is just because
      presumably XtraDB will eventually be updated to MySQL 5.7-based InnoDB
      as well, so there is little need to modify the existing code only for
      clean-up purposes.
      
      The old synchronous function thd_report_wait_for() is no longer used
      and removed in this patch.
      Signed-off-by: default avatarKristian Nielsen <knielsen@knielsen-hq.org>
      cc49f009
  2. 16 Oct, 2016 2 commits
  3. 15 Oct, 2016 1 commit
  4. 14 Oct, 2016 9 commits
  5. 13 Oct, 2016 1 commit
  6. 10 Oct, 2016 1 commit
  7. 09 Oct, 2016 2 commits
  8. 08 Oct, 2016 6 commits
  9. 07 Oct, 2016 6 commits
  10. 06 Oct, 2016 1 commit
  11. 04 Oct, 2016 5 commits
    • Monty's avatar
      After merge and bug fixes · 14b1c8c8
      Monty authored
      - Fixed compiler warnings
      - Removed have_debug.inc from innochecksum_3
      - Fixed race condition in innodb_buffer_pool_load
      - Fixed merge issue in innodb-bad-key-change.test
      - Fixed missing array allocation that could cause
        function_defaults_notembedded to fail
      - Fixed thread_cache_size_func
      14b1c8c8
    • Monty's avatar
      Remove end . from error messages to get them consistent · af7490f9
      Monty authored
      Fixed a few failing tests
      af7490f9
    • Monty's avatar
      Fixed compiler warnings and failing tests · c1125c32
      Monty authored
      c1125c32
    • Monty's avatar
      Use sql_mode_t for sql_mode. · 7b96416f
      Monty authored
      This fixed several cases where we where using just ulong for sql_mode
      7b96416f
    • Monty's avatar
      MDEV-6112 multiple triggers per table · 8be53a38
      Monty authored
      This is similar to MysQL Worklog 3253, but with
      a different implementation. The disk format and
      SQL syntax is identical with MySQL 5.7.
      
      Fetures supported:
      - "Any" ammount of any trigger
      - Supports FOLLOWS and PRECEDES to be
        able to put triggers in a certain execution order.
      
      Implementation details:
      - Class Trigger added to hold information about a trigger.
        Before this trigger information was stored in a set of lists in
        Table_triggers_list and in Table_triggers_list::bodies
      - Each Trigger has a next field that poinst to the next Trigger with the
        same action and time.
      - When accessing a trigger, we now always access all linked triggers
      - The list are now only used to load and save trigger files.
      - MySQL trigger test case (trigger_wl3253) added and we execute these
        identically.
      - Even more gracefully handling of wrong trigger files than before. This
        is useful if a trigger file uses functions or syntax not provided by
        the server.
      - Each trigger now has a "Created" field that shows when the trigger was
        created, with 2 decimals.
      
      Other comments:
      - Many of the changes in test files was done because of the new "Created"
        field in the trigger file. This shows up in SHOW ... TRIGGER and when
        using information_schema.trigger.
      - Don't check if all memory is released if on uses --gdb;  This is needed
        to be able to get a list from safemalloc of not freed memory while
        debugging.
      - Added option to trim_whitespace() to know how many prefix characters
        was skipped.
      - Changed a few ulonglong sql_mode to sql_mode_t, to find some wrong usage
        of sql_mode.
      8be53a38