Commit graph

17 commits

Author SHA1 Message Date
Oleksandr Byelkin
31081593aa Merge branch '11.0' into 10.1 2018-09-06 22:45:19 +02:00
Oleksandr Byelkin
d527bf5390 Merge branch 'merge-tokudb-5.6' into 10.0 2018-09-06 21:04:56 +02:00
Oleksandr Byelkin
a816eac92a 5.6.41-84.1 2018-09-03 16:29:29 +02:00
Sergei Golubchik
d4df7bc9b1 Merge branch 'github/10.0' into 10.1 2018-02-02 10:09:44 +01:00
Vicențiu Ciorbaru
c5f333adb6 Merge branch 'merge-tokudb-5.6' into 10.0 2018-01-24 17:26:15 +02:00
Vicențiu Ciorbaru
f6716cef7e 5.6.38-83.0 2018-01-23 19:20:10 +02:00
Sergei Golubchik
8e8d42ddf0 Merge branch '10.0' into 10.1 2017-08-08 10:18:43 +02:00
Vicențiu Ciorbaru
40e213f210 Merge branch 'merge-tokudb-5.6' into 10.0 2017-08-03 12:11:31 +03:00
Vicențiu Ciorbaru
b1a2031ff9 5.6.36-82.1 2017-08-03 11:48:44 +03:00
Kristian Nielsen
021f78f695 Use thd_kill_level() over old thd_killed() in TokuDB. 2016-11-23 16:49:42 +01:00
Kristian Nielsen
d145d1b6ee fix bogus stalls in the lock tree for low concurrency applications
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.
2016-11-23 16:48:31 +01:00
Sergei Golubchik
078e510e0a Merge branch 'merge/merge-tokudb-5.6' into 10.0 2016-09-27 19:03:11 +02:00
Sergei Golubchik
e312e2e636 5.6.32-78.1 2016-09-27 17:59:58 +02:00
Sergei Golubchik
dde558f262 Merge branch 'merge-tokudb-5.6' into 10.0-tokudb-merge 2016-06-11 01:06:09 +02:00
Sergei Golubchik
ca95cc603b Merge branch 'merge-tokudb-5.6' into 10.0-tokudb-merge
5.6.28-76.1
2016-06-10 20:48:59 +02:00
Sergei Golubchik
30d9d4e26d 5.6.29-76.2 2016-04-26 20:58:29 +02:00
Sergei Golubchik
dcc501aec3 5.6.27-76.0 2015-12-15 17:23:58 +01:00