1 files changed, 26 insertions, 37 deletions
diff --git a/src/third_party/wiredtiger/src/btree/bt_curnext.c b/src/third_party/wiredtiger/src/btree/bt_curnext.c
index d4ebd5322f4..b7f2e0db4b3 100644
--- a/src/third_party/wiredtiger/src/btree/bt_curnext.c
+++ b/src/third_party/wiredtiger/src/btree/bt_curnext.c
@@ -41,20 +41,17 @@ __cursor_fix_append_next(WT_CURSOR_BTREE *cbt, bool newpage, bool restart)
     __cursor_set_recno(cbt, cbt->recno + 1);
 
     /*
-     * Fixed-width column store appends are inherently non-transactional.
-     * Even a non-visible update by a concurrent or aborted transaction
-     * changes the effective end of the data.  The effect is subtle because
-     * of the blurring between deleted and empty values, but ideally we
-     * would skip all uncommitted changes at the end of the data.  This
-     * doesn't apply to variable-width column stores because the implicitly
-     * created records written by reconciliation are deleted and so can be
-     * never seen by a read.
+     * Fixed-width column store appends are inherently non-transactional. Even a non-visible update
+     * by a concurrent or aborted transaction changes the effective end of the data. The effect is
+     * subtle because of the blurring between deleted and empty values, but ideally we would skip
+     * all uncommitted changes at the end of the data. This doesn't apply to variable-width column
+     * stores because the implicitly created records written by reconciliation are deleted and so
+     * can be never seen by a read.
      *
-     * The problem is that we don't know at this point whether there may be
-     * multiple uncommitted changes at the end of the data, and it would be
-     * expensive to check every time we hit an aborted update.  If an
-     * insert is aborted, we simply return zero (empty), regardless of
-     * whether we are at the end of the data.
+     * The problem is that we don't know at this point whether there may be multiple uncommitted
+     * changes at the end of the data, and it would be expensive to check every time we hit an
+     * aborted update. If an insert is aborted, we simply return zero (empty), regardless of whether
+     * we are at the end of the data.
      */
     if (cbt->recno < WT_INSERT_RECNO(cbt->ins)) {
         cbt->v = 0;
@@ -249,14 +246,12 @@ __cursor_var_next(WT_CURSOR_BTREE *cbt, bool newpage, bool restart)
                     continue;
 
                 /*
-                 * There can be huge gaps in the variable-length
-                 * column-store name space appearing as deleted
-                 * records. If more than one deleted record, do
-                 * the work of finding the next record to return
-                 * instead of looping through the records.
+                 * There can be huge gaps in the variable-length column-store name space appearing
+                 * as deleted records. If more than one deleted record, do the work of finding the
+                 * next record to return instead of looping through the records.
                  *
-                 * First, find the smallest record in the update
-                 * list that's larger than the current record.
+                 * First, find the smallest record in the update list that's larger than the current
+                 * record.
                  */
                 ins = __col_insert_search_gt(cbt->ins_head, cbt->recno);
 
@@ -313,13 +308,11 @@ __cursor_row_next(WT_CURSOR_BTREE *cbt, bool newpage, bool restart)
     cbt->iter_retry = WT_CBT_RETRY_NOTSET;
 
     /*
-     * For row-store pages, we need a single item that tells us the part
-     * of the page we're walking (otherwise switching from next to prev
-     * and vice-versa is just too complicated), so we map the WT_ROW and
-     * WT_INSERT_HEAD insert array slots into a single name space: slot 1
-     * is the "smallest key insert list", slot 2 is WT_ROW[0], slot 3 is
-     * WT_INSERT_HEAD[0], and so on.  This means WT_INSERT lists are
-     * odd-numbered slots, and WT_ROW array slots are even-numbered slots.
+     * For row-store pages, we need a single item that tells us the part of the page we're walking
+     * (otherwise switching from next to prev and vice-versa is just too complicated), so we map the
+     * WT_ROW and WT_INSERT_HEAD insert array slots into a single name space: slot 1 is the
+     * "smallest key insert list", slot 2 is WT_ROW[0], slot 3 is WT_INSERT_HEAD[0], and so on. This
+     * means WT_INSERT lists are odd-numbered slots, and WT_ROW array slots are even-numbered slots.
      *
      * Initialize for each new page.
      */
@@ -696,17 +689,13 @@ err:
         F_SET(cursor, WT_CURSTD_KEY_INT | WT_CURSTD_VALUE_INT);
 #ifdef HAVE_DIAGNOSTIC
         /*
-         * Skip key order check, if prev is called after a next returned
-         * a prepare conflict error, i.e cursor has changed direction
-         * at a prepared update, hence current key returned could be
-         * same as earlier returned key.
+         * Skip key order check, if prev is called after a next returned a prepare conflict error,
+         * i.e cursor has changed direction at a prepared update, hence current key returned could
+         * be same as earlier returned key.
          *
-         * eg: Initial data set : (1,2,3,...10)
-         * insert key 11 in a prepare transaction.
-         * loop on next will return 1,2,3...10 and subsequent call to
-         * next will return a prepare conflict. Now if we call prev
-         * key 10 will be returned which will be same as earlier
-         * returned key.
+         * eg: Initial data set : (1,2,3,...10) insert key 11 in a prepare transaction. loop on next
+         * will return 1,2,3...10 and subsequent call to next will return a prepare conflict. Now if
+         * we call prev key 10 will be returned which will be same as earlier returned key.
          */
         if (!F_ISSET(cbt, WT_CBT_ITERATE_RETRY_PREV))
             ret = __wt_cursor_key_order_check(session, cbt, true);