Commit 1db7d8f6 authored by Mattias Jonsson's avatar Mattias Jonsson

Bug#40595: Non-matching rows not released with READ-COMMITTED on tables

with partitions

Pre push fix, optimized replace_regex, to cut 2 seconds
from test time.
parents cba27433 a5ec6953
drop table if exists t1;
CREATE TABLE t1 (id INT PRIMARY KEY, data INT) ENGINE = InnoDB
PARTITION BY RANGE(id) (
PARTITION p0 VALUES LESS THAN (5),
PARTITION p1 VALUES LESS THAN (10),
PARTITION p2 VALUES LESS THAN MAXVALUE
);
INSERT INTO t1 VALUES (1,1), (2,2), (3,3), (4,4), (5,5), (6,6), (7,7), (8,8),
(9,9), (10,10), (11,11);
SET @old_tx_isolation := @@session.tx_isolation;
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
SET autocommit = 0;
UPDATE t1 SET DATA = data*2 WHERE id = 3;
SHOW ENGINE InnoDB STATUS;
Type Name Status
InnoDB 2 lock struct(s) 1 row lock(s)
UPDATE t1 SET data = data*2 WHERE data = 2;
SHOW ENGINE InnoDB STATUS;
Type Name Status
InnoDB 6 lock struct(s) 2 row lock(s)
SET @@session.tx_isolation = @old_tx_isolation;
DROP TABLE t1;
# Bug#37721, test of ORDER BY on PK and WHERE on INDEX
CREATE TABLE t1 (
a INT,
......
--source include/have_partition.inc
--source include/have_innodb.inc
--disable_warnings
drop table if exists t1;
--enable_warnings
#
# Bug#40595: Non-matching rows not released with READ-COMMITTED on tables
# with partitions
CREATE TABLE t1 (id INT PRIMARY KEY, data INT) ENGINE = InnoDB
PARTITION BY RANGE(id) (
PARTITION p0 VALUES LESS THAN (5),
PARTITION p1 VALUES LESS THAN (10),
PARTITION p2 VALUES LESS THAN MAXVALUE
);
INSERT INTO t1 VALUES (1,1), (2,2), (3,3), (4,4), (5,5), (6,6), (7,7), (8,8),
(9,9), (10,10), (11,11);
SET @old_tx_isolation := @@session.tx_isolation;
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
SET autocommit = 0;
UPDATE t1 SET DATA = data*2 WHERE id = 3;
# grouping/referencing in replace_regex is very slow on long strings,
# removing all before/after the interesting row before grouping/referencing
--replace_regex /.*---TRANSACTION [0-9]+ [0-9]+, .*, OS thread id [0-9]+// /MySQL thread id [0-9]+, query id [0-9]+ .*// /.*([0-9]+ lock struct\(s\)), heap size [0-9]+, ([0-9]+ row lock\(s\)).*/\1 \2/
SHOW ENGINE InnoDB STATUS;
UPDATE t1 SET data = data*2 WHERE data = 2;
# grouping/referencing in replace_regex is very slow on long strings,
# removing all before/after the interesting row before grouping/referencing
--replace_regex /.*---TRANSACTION [0-9]+ [0-9]+, .*, OS thread id [0-9]+// /MySQL thread id [0-9]+, query id [0-9]+ .*// /.*([0-9]+ lock struct\(s\)), heap size [0-9]+, ([0-9]+ row lock\(s\)).*/\1 \2/
SHOW ENGINE InnoDB STATUS;
SET @@session.tx_isolation = @old_tx_isolation;
DROP TABLE t1;
#
# Bug37721: ORDER BY when WHERE contains non-partitioned index column
# wrong order since it did not use pk as second compare
......
......@@ -2813,8 +2813,42 @@ uint ha_partition::lock_count() const
void ha_partition::unlock_row()
{
DBUG_ENTER("ha_partition::unlock_row");
m_file[m_last_part]->unlock_row();
return;
DBUG_VOID_RETURN;
}
/**
Use semi consistent read if possible
SYNOPSIS
try_semi_consistent_read()
yes Turn on semi consistent read
RETURN VALUE
NONE
DESCRIPTION
See handler.h:
Tell the engine whether it should avoid unnecessary lock waits.
If yes, in an UPDATE or DELETE, if the row under the cursor was locked
by another transaction, the engine may try an optimistic read of
the last committed row value under the cursor.
Note: prune_partitions are already called before this call, so using
pruning is OK.
*/
void ha_partition::try_semi_consistent_read(bool yes)
{
handler **file;
DBUG_ENTER("ha_partition::try_semi_consistent_read");
for (file= m_file; *file; file++)
{
if (bitmap_is_set(&(m_part_info->used_partitions), (file - m_file)))
(*file)->try_semi_consistent_read(yes);
}
DBUG_VOID_RETURN;
}
......
......@@ -325,6 +325,10 @@ public:
Call to unlock rows not to be updated in transaction
*/
virtual void unlock_row();
/*
Call to hint about semi consistent read
*/
virtual void try_semi_consistent_read(bool);
/*
-------------------------------------------------------------------------
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment