postgrespro.git / summary / log / commit / refs

commit    60f3cc9553c7ea7a1cc61bcd1efe51537f31e531
Author:   Peter Geoghegan <pg@bowt.ie>
Date:     Wed Dec 19 00:59:50 2018 +0000

    Correct obsolete nbtree recovery comments.
    
    Commit 40dae7ec537, which made the handling of interrupted nbtree page
    splits more robust, removed an nbtree-specific end-of-recovery cleanup
    step.  This meant that it was no longer possible to complete an
    interrupted page split during recovery.  However, a reference to
    recovery as a reason for using a NULL stack while inserting into a
    parent page was missed.  Remove the reference.
    
    Remove a similar obsolete reference to recovery that was introduced much
    more recently, as part of the btree fastpath optimization enhancement
    that made it into Postgres 11 (commit 2b272734, and follow-up commits).
    
    Backpatch: 11-, where the fastpath optimization was introduced.


 src/backend/access/nbtree/nbtinsert.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/backend/access/nbtree/nbtinsert.c b/src/backend/access/nbtree/nbtinsert.c
index 582e5b0652..80437cc831 100644
--- a/src/backend/access/nbtree/nbtinsert.c
+++ b/src/backend/access/nbtree/nbtinsert.c
@@ -876,10 +876,10 @@ _bt_insertonpg(Relation rel,
 		 * all the required conditions, including the fact that this page has
 		 * enough freespace. Note that this routine can in theory deal with
 		 * the situation where a NULL stack pointer is passed (that's what
-		 * would happen if the fastpath is taken), like it does during crash
-		 * recovery. But that path is much slower, defeating the very purpose
-		 * of the optimization.  The following assertion should protect us
-		 * from any future code changes that invalidate those assumptions.
+		 * would happen if the fastpath is taken). But that path is much
+		 * slower, defeating the very purpose of the optimization.  The
+		 * following assertion should protect us from any future code changes
+		 * that invalidate those assumptions.
 		 *
 		 * Note that whenever we fail to take the fastpath, we clear the
 		 * cached block. Checking for a valid cached block at this point is
@@ -1807,8 +1807,8 @@ _bt_checksplitloc(FindSplitData *state,
  * and it'd be possible for some other process to try to split or delete
  * one of these pages, and get confused because it cannot find the downlink.)
  *
- * stack - stack showing how we got here.  May be NULL in cases that don't
- *			have to be efficient (concurrent ROOT split, WAL recovery)
+ * stack - stack showing how we got here.  Will be NULL when splitting true
+ *			root, or during concurrent root split, where we can be inefficient
  * is_root - we split the true root
  * is_only - we split a page alone on its level (might have been fast root)
  */


[parent: 3cab54878dbf]