We don't need to do a search in the row-store cursor truncate setup code,

the WT_SESSION.truncate API code already did one.

This does not mean WT_SESSION.truncate can't return WT_NOTFOUND in some
cases, the first thing cursor truncate does is a cursor remove call in
order to acquire the page's write generation information -- that remove
call does the usual "discard my current reference and get a new one"
work, which allows another deleting thread to race and remove one of the
truncate's start/stop keys.

Reference SERVER-17141.

1 files changed, 6 insertions, 8 deletions

diff --git a/src/btree/bt_cursor.c b/src/btree/bt_cursor.c
index 1960e4605ef..7d7ed30326d 100644
--- a/src/btree/bt_cursor.c
+++ b/src/btree/bt_cursor.c
@@ -1081,15 +1081,13 @@ __wt_btcur_range_truncate(WT_CURSOR_BTREE *start, WT_CURSOR_BTREE *stop)
 		 * fully instantiated when truncating row-store objects because
 		 * it's comparing page and/or skiplist positions, not keys. (Key
 		 * comparison would work, it's only that a key comparison would
-		 * be relatively expensive.  Column-store objects have record
-		 * number keys, so the key comparison is cheap.)  Cursors may
-		 * have only had their keys set, so we must ensure the cursors
-		 * are positioned in the tree.
+		 * be relatively expensive, especially with custom collators.
+		 * Column-store objects have record number keys, so the key
+		 * comparison is cheap.)  The session truncate code did cursor
+		 * searches when setting up the truncate so we're good to go: if
+		 * that ever changes, we'd need to do something here to ensure a
+		 * fully instantiated cursor.
 		 */
-		if (start != NULL)
-			WT_ERR(__wt_btcur_search(start));
-		if (stop != NULL)
-			WT_ERR(__wt_btcur_search(stop));
 		WT_ERR(__cursor_truncate(
 		    session, start, stop, __cursor_row_modify));
 		break;