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

Skip to content

Commit cfe41f9

Browse files
Backpatch nbtree page deletion hardening.
Postgres 14 commit 5b861ba taught nbtree VACUUM to tolerate buggy opclasses. VACUUM's inability to locate a to-be-deleted page's downlink in the parent page was logged instead of throwing an error. VACUUM could just press on with vacuuming the index, and vacuuming the table as a whole. There are now anecdotal reports of this error causing problems that were much more disruptive than the underlying index corruption ever could be. Anything that makes VACUUM unable to make forward progress against one table/index ultimately risks making the system enter xidStopLimit mode. There is no good reason to take any chances here, so backpatch the hardening commit. Author: Peter Geoghegan <[email protected]> Discussion: https://postgr.es/m/CAH2-Wzm9HR6Pow=t-iQa57zT8qmX6_M4h14F-pTtb=xFDW5FBA@mail.gmail.com Backpatch: 10-13 (all supported versions that lacked the hardening)
1 parent e5a5b97 commit cfe41f9

File tree

1 file changed

+19
-2
lines changed

1 file changed

+19
-2
lines changed

src/backend/access/nbtree/nbtpage.c

Lines changed: 19 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -995,8 +995,25 @@ _bt_lock_branch_parent(Relation rel, BlockNumber child, BTStack stack,
995995
ItemPointerSet(&(stack->bts_btentry.t_tid), child, P_HIKEY);
996996
pbuf = _bt_getstackbuf(rel, stack, BT_WRITE);
997997
if (pbuf == InvalidBuffer)
998-
elog(ERROR, "failed to re-find parent key in index \"%s\" for deletion target page %u",
999-
RelationGetRelationName(rel), child);
998+
{
999+
/*
1000+
* Failed to "re-find" a pivot tuple whose downlink matched our child
1001+
* block number on the parent level -- the index must be corrupt.
1002+
* Don't even try to delete the leafbuf subtree. Just report the
1003+
* issue and press on with vacuuming the index.
1004+
*
1005+
* Note: _bt_getstackbuf() recovers from concurrent page splits that
1006+
* take place on the parent level. Its approach is a near-exhaustive
1007+
* linear search. This also gives it a surprisingly good chance of
1008+
* recovering in the event of a buggy or inconsistent opclass. But we
1009+
* don't rely on that here.
1010+
*/
1011+
ereport(LOG,
1012+
(errcode(ERRCODE_INDEX_CORRUPTED),
1013+
errmsg_internal("failed to re-find parent key in index \"%s\" for deletion target page %u",
1014+
RelationGetRelationName(rel), child)));
1015+
return false;
1016+
}
10001017
parent = stack->bts_blkno;
10011018
poffset = stack->bts_offset;
10021019

0 commit comments

Comments
 (0)