1. 02 Dec, 2016 3 commits
  2. 29 Nov, 2016 2 commits
  3. 28 Nov, 2016 1 commit
  4. 25 Nov, 2016 3 commits
    • Marko Mäkelä's avatar
      MDEV-11349 (2/2) Fix some bogus-looking Valgrind warnings · a68d1352
      Marko Mäkelä authored
      buf_block_init(): Initialize buf_page_t::flush_type.
      For some reason, Valgrind 3.12.0 would seem to flag some
      bits in adjacent bitfields as uninitialized, even though only
      the two bits of flush_type were left uninitialized. Initialize
      the field to get rid of many warnings.
      
      buf_page_init_low(): Initialize buf_page_t::old.
      For some reason, Valgrind 3.12.0 would seem to flag all 32
      bits uninitialized when buf_page_init_for_read() invokes
      buf_LRU_add_block(bpage, TRUE). This would trigger bogus warnings
      for buf_page_t::freed_page_clock being uninitialized.
      (The V-bits would later claim that only "old" is initialized
      in the 32-bit word.) Perhaps recent compilers
      (GCC 6.2.1 and clang 4.0.0) generate more optimized x86_64 code
      for bitfield operations, confusing Valgrind?
      
      mach_write_to_1(), mach_write_to_2(), mach_write_to_3():
      Rewrite the assertions that ensure that the most significant
      bits are zero. Apparently, clang 4.0.0 would optimize expressions
      of the form ((n | 0xFF) <= 0x100) to (n <= 0x100). The redundant
      0xFF was added in the first place in order to suppress a
      Valgrind warning. (Valgrind would warn about comparing uninitialized
      values even in the case when the uninitialized bits do not affect
      the result of the comparison.)
      a68d1352
    • Kristian Nielsen's avatar
      3bec0b32
    • Marko Mäkelä's avatar
      MDEV-11349 (1/2) Fix some clang 4.0 warnings · 8da33e3a
      Marko Mäkelä authored
      In InnoDB and XtraDB functions that declare pointer parameters as nonnull,
      remove nullness checks, because GCC would optimize them away anyway.
      
      Use #ifdef instead of #if when checking for a configuration flag.
      
      Clang says that left shifts of negative values are undefined.
      So, use ~0U instead of ~0 in a number of macros.
      
      Some functions that were defined as UNIV_INLINE were declared as
      UNIV_INTERN. Consistently use the same type of linkage.
      
      ibuf_merge_or_delete_for_page() could pass bitmap_page=NULL to
      buf_page_print(), conflicting with the __attribute__((nonnull)).
      8da33e3a
  5. 24 Nov, 2016 1 commit
  6. 23 Nov, 2016 3 commits
    • Kristian Nielsen's avatar
      021f78f6
    • Kristian Nielsen's avatar
      Fix optimistic parallel replication for TokuDB. · 660a2928
      Kristian Nielsen authored
      Make TokuDB report row lock waits with thd_rpl_deadlock_check(). This allows
      parallel replication to properly detect conflicts, and kill and retry the
      offending transaction.
      660a2928
    • Kristian Nielsen's avatar
      fix bogus stalls in the lock tree for low concurrency applications · d145d1b6
      Kristian Nielsen authored
      Merge into the MariaDB tree the pull request from Rich Prohaska for
      PerconaFT. These changes are needed to get parallel replication to
      work with TokuDB. Once the pull request is accepted by Percona and the new upstream version enters MariaDB, this commit can be superseded.
      
      Original commit message from Rich Prohaska:
      
          1. Fix the release before wait race
      
          The release before wait race occurs when a lock is released by transaction A after transaction B tried to acquire it but before transaction B has a chance to register it's pending lock request.  There are several ways to fix this problem, but we want to optimize for the common situation of minimal lock conflicts, which is what the lock acquisition algorithm currently does.  Our solution to the release before wait race is for transaction B to retry its lock request after its lock request has been added to the pending lock set.
      
          2. Fix the retry race
      
          The retry race occurs in the current lock retry algorithm which assumes that if some transaction is running lock retry, then my transaction does not also need to run it.  There is a chance that some pending lock requests will be skipped, but these lock requests will eventually time out.  For applications with small numbers of concurrent transactions, timeouts will frequently occur, and the application throughput will be very small.
      
          The solution to the retry race is to use a group retry algorithm.  All threads run through the retry logic.  Sequence numbers are used to group retries into batches such that one transaction can run the retry logic on behalf of several transactions.  This amortizes the retry cost.  The sequence numbers also ensure that when a transaction releases its locks, all of the pending lock requests that it is blocking are retried.
      
          3. Implement a mechanism to find and kill a pending lock request
      
          Tags lock requests with a client id, use the client id as a key into the pending lock requests sets to find a lock request, complete the lock request with a lock timeout error.
      
          Copyright (c) 2016, Rich Prohaska
          All rights reserved.
      
          Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
      
          1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
      
          2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
      
          THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
      d145d1b6
  7. 22 Nov, 2016 2 commits
  8. 16 Nov, 2016 1 commit
  9. 15 Nov, 2016 1 commit
  10. 14 Nov, 2016 1 commit
  11. 09 Nov, 2016 1 commit
  12. 08 Nov, 2016 1 commit
  13. 07 Nov, 2016 1 commit
  14. 04 Nov, 2016 4 commits
  15. 03 Nov, 2016 3 commits
  16. 02 Nov, 2016 12 commits