Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 60f3cc9

Browse files
Correct obsolete nbtree recovery comments.
Commit 40dae7e, 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 2b27273, and follow-up commits). Backpatch: 11-, where the fastpath optimization was introduced.
1 parent 3cab548 commit 60f3cc9

File tree

1 file changed

+6
-6
lines changed

1 file changed

+6
-6
lines changed

src/backend/access/nbtree/nbtinsert.c

Lines changed: 6 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -876,10 +876,10 @@ _bt_insertonpg(Relation rel,
876876
* all the required conditions, including the fact that this page has
877877
* enough freespace. Note that this routine can in theory deal with
878878
* the situation where a NULL stack pointer is passed (that's what
879-
* would happen if the fastpath is taken), like it does during crash
880-
* recovery. But that path is much slower, defeating the very purpose
881-
* of the optimization. The following assertion should protect us
882-
* from any future code changes that invalidate those assumptions.
879+
* would happen if the fastpath is taken). But that path is much
880+
* slower, defeating the very purpose of the optimization. The
881+
* following assertion should protect us from any future code changes
882+
* that invalidate those assumptions.
883883
*
884884
* Note that whenever we fail to take the fastpath, we clear the
885885
* cached block. Checking for a valid cached block at this point is
@@ -1807,8 +1807,8 @@ _bt_checksplitloc(FindSplitData *state,
18071807
* and it'd be possible for some other process to try to split or delete
18081808
* one of these pages, and get confused because it cannot find the downlink.)
18091809
*
1810-
* stack - stack showing how we got here. May be NULL in cases that don't
1811-
* have to be efficient (concurrent ROOT split, WAL recovery)
1810+
* stack - stack showing how we got here. Will be NULL when splitting true
1811+
* root, or during concurrent root split, where we can be inefficient
18121812
* is_root - we split the true root
18131813
* is_only - we split a page alone on its level (might have been fast root)
18141814
*/

0 commit comments

Comments
 (0)