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

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)