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

Commit 741c4c4

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 84fcc2c commit 741c4c4

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
@@ -887,10 +887,10 @@ _bt_insertonpg(Relation rel,
887887
* all the required conditions, including the fact that this page has
888888
* enough freespace. Note that this routine can in theory deal with
889889
* the situation where a NULL stack pointer is passed (that's what
890-
* would happen if the fastpath is taken), like it does during crash
891-
* recovery. But that path is much slower, defeating the very purpose
892-
* of the optimization. The following assertion should protect us
893-
* from any future code changes that invalidate those assumptions.
890+
* would happen if the fastpath is taken). But that path is much
891+
* slower, defeating the very purpose of the optimization. The
892+
* following assertion should protect us from any future code changes
893+
* that invalidate those assumptions.
894894
*
895895
* Note that whenever we fail to take the fastpath, we clear the
896896
* cached block. Checking for a valid cached block at this point is
@@ -1818,8 +1818,8 @@ _bt_checksplitloc(FindSplitData *state,
18181818
* and it'd be possible for some other process to try to split or delete
18191819
* one of these pages, and get confused because it cannot find the downlink.)
18201820
*
1821-
* stack - stack showing how we got here. May be NULL in cases that don't
1822-
* have to be efficient (concurrent ROOT split, WAL recovery)
1821+
* stack - stack showing how we got here. Will be NULL when splitting true
1822+
* root, or during concurrent root split, where we can be inefficient
18231823
* is_root - we split the true root
18241824
* is_only - we split a page alone on its level (might have been fast root)
18251825
*/

0 commit comments

Comments
 (0)