summaryrefslogtreecommitdiff
path: root/sql/ha_partition.cc
diff options
context:
space:
mode:
authorMattias Jonsson <mattias.jonsson@sun.com>2008-12-16 12:44:18 +0100
committerMattias Jonsson <mattias.jonsson@sun.com>2008-12-16 12:44:18 +0100
commit23d569edcea37c1dbb48fa2933ab476120476546 (patch)
treed9ef4bd6fe6d08f63bfacc3b96869d01f947d0c9 /sql/ha_partition.cc
parent207d519a080e6df0d2ec57a1abc784f2043f366c (diff)
downloadmariadb-git-23d569edcea37c1dbb48fa2933ab476120476546.tar.gz
post push fix for bug#40595
Addition of hander function was_semi_consistent_read mysql-test/r/partition_innodb_semi_consistent.result: post push fix for bug#40595 Addition of hander function was_semi_consistent_read Added test result mysql-test/t/partition_innodb_semi_consistent-master.opt: post push fix for bug#40595 Addition of hander function was_semi_consistent_read Added test opt file mysql-test/t/partition_innodb_semi_consistent.test: post push fix for bug#40595 Addition of hander function was_semi_consistent_read Added test case sql/ha_partition.cc: post push fix for bug#40595 Addition of hander function was_semi_consistent_read The lack of was_semi_consistent_read opened a regression for bug-31310 when useing a partitioned InnoDB table
Diffstat (limited to 'sql/ha_partition.cc')
-rw-r--r--sql/ha_partition.cc30
1 files changed, 30 insertions, 0 deletions
diff --git a/sql/ha_partition.cc b/sql/ha_partition.cc
index 852f437b213..47d2d36ac8d 100644
--- a/sql/ha_partition.cc
+++ b/sql/ha_partition.cc
@@ -2818,6 +2818,36 @@ void ha_partition::unlock_row()
DBUG_VOID_RETURN;
}
+/**
+ Check if semi consistent read was used
+
+ SYNOPSIS
+ was_semi_consistent_read()
+
+ RETURN VALUE
+ TRUE Previous read was a semi consistent read
+ FALSE Previous read was not a semi consistent read
+
+ DESCRIPTION
+ See handler.h:
+ In an UPDATE or DELETE, if the row under the cursor was locked by another
+ transaction, and the engine used an optimistic read of the last
+ committed row value under the cursor, then the engine returns 1 from this
+ function. MySQL must NOT try to update this optimistic value. If the
+ optimistic value does not match the WHERE condition, MySQL can decide to
+ skip over this row. Currently only works for InnoDB. This can be used to
+ avoid unnecessary lock waits.
+
+ If this method returns nonzero, it will also signal the storage
+ engine that the next read will be a locking re-read of the row.
+*/
+bool ha_partition::was_semi_consistent_read()
+{
+ DBUG_ENTER("ha_partition::was_semi_consistent_read");
+ DBUG_ASSERT(m_last_part < m_tot_parts &&
+ bitmap_is_set(&(m_part_info->used_partitions), m_last_part));
+ DBUG_RETURN(m_file[m_last_part]->was_semi_consistent_read());
+}
/**
Use semi consistent read if possible