Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commitfe97c61

Browse files
Update nbtree LP_DEAD item deletion comments.
Comments about the consequences of clearing the BTP_HAS_GARBAGE pageflag bit that apply only to VACUUM were added to code that deals withopportunistic deletion of LP_DEAD items by commita760893. The samecomment block was added to both _bt_delitems_vacuum() and_bt_delitems_delete(). Correct _bt_delitems_delete()'s copy of thecomment block._bt_delitems_delete() reliably deletes items that were found by callerto have their LP_DEAD bit set. There is no question about whether ornot unsetting the BTP_HAS_GARBAGE bit can miss some LP_DEAD items thatwere set recently.Also tweak a related section of the nbtree README.
1 parentb265aa1 commitfe97c61

File tree

2 files changed

+6
-13
lines changed

2 files changed

+6
-13
lines changed

‎src/backend/access/nbtree/README

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -559,15 +559,15 @@ writer cannot observe the incomplete split flag before the first writer
559559
finishes the split. If we let concurrent writers on the primary observe
560560
an incomplete split flag on the same page, each writer would attempt to
561561
complete the unfinished split, corrupting the parent page. (Similarly,
562-
replay of page deletion records does not hold a write lock on theleaf
563-
page throughout; only the primary needs toblocks out concurrent writers
564-
that insert on to the page being deleted.)
562+
replay of page deletion records does not hold a write lock on thetarget
563+
leafpage throughout; only the primary needs toblock out concurrent
564+
writersthat insert on to the page being deleted.)
565565

566566
During recovery all index scans start with ignore_killed_tuples = false
567567
and we never set kill_prior_tuple. We do this because the oldest xmin
568568
on the standby server can be older than the oldest xmin on the master
569569
server, which means tuples can be marked LP_DEAD even when they are
570-
still visible on the standby. We don't WAL log tuple LP_DEADbits, but
570+
still visible on the standby. We don't WAL log tuple LP_DEAD bits, but
571571
they can still appear in the standby because of full page writes. So
572572
we must always ignore them in standby, and that means it's not worth
573573
setting them either. (When LP_DEAD-marked tuples are eventually deleted

‎src/backend/access/nbtree/nbtpage.c

Lines changed: 2 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -1074,15 +1074,8 @@ _bt_delitems_delete(Relation rel, Buffer buf,
10741074

10751075
/*
10761076
* Unlike _bt_delitems_vacuum, we *must not* clear the vacuum cycle ID,
1077-
* because this is not called by VACUUM.
1078-
*/
1079-
1080-
/*
1081-
* Mark the page as not containing any LP_DEAD items. This is not
1082-
* certainly true (there might be some that have recently been marked, but
1083-
* weren't included in our target-item list), but it will almost always be
1084-
* true and it doesn't seem worth an additional page scan to check it.
1085-
* Remember that BTP_HAS_GARBAGE is only a hint anyway.
1077+
* because this is not called by VACUUM. Just clear the BTP_HAS_GARBAGE
1078+
* page flag, since we deleted all items with their LP_DEAD bit set.
10861079
*/
10871080
opaque= (BTPageOpaque)PageGetSpecialPointer(page);
10881081
opaque->btpo_flags &= ~BTP_HAS_GARBAGE;

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp