Thanks to visit codestin.com
Credit goes to github.com

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)