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

Commitb631182

Browse files
nbtree VACUUM: cope with topparent inconsistencies.
Avoid "right sibling %u of block %u is not next child" errors whenvacuuming a corrupt nbtree index. Just LOG the issue and press on.That way VACUUM will have a decent chance of finishing off all requiredprocessing for the index (and for the table as a whole).This is similar to recent work from commit5abff19, as well as workfrom commit5b861ba (later backpatched as commit43e409c), whichtaught nbtree VACUUM to keep going when its "re-find" check fails. Thehardening added by this commit takes place directly after the "re-find"check, right before the critical section for the first stage of pagedeletion.Author: Peter Geoghegan <pg@bowt.ie>Discussion:https://postgr.es/m/CAH2-Wz=dayg0vjs4+er84TS9ami=csdzjpuiCGbEw=idhwqhzQ@mail.gmail.comBackpatch: 11- (all supported versions).
1 parente966b3d commitb631182

File tree

1 file changed

+16
-7
lines changed

1 file changed

+16
-7
lines changed

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

Lines changed: 16 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -1772,12 +1772,6 @@ _bt_mark_page_halfdead(Relation rel, Buffer leafbuf, BTStack stack)
17721772
&topparent,&topparentrightsib))
17731773
return false;
17741774

1775-
/*
1776-
* Check that the parent-page index items we're about to delete/overwrite
1777-
* in subtree parent page contain what we expect. This can fail if the
1778-
* index has become corrupt for some reason. We want to throw any error
1779-
* before entering the critical section --- otherwise it'd be a PANIC.
1780-
*/
17811775
page=BufferGetPage(subtreeparent);
17821776
opaque= (BTPageOpaque)PageGetSpecialPointer(page);
17831777

@@ -1795,15 +1789,29 @@ _bt_mark_page_halfdead(Relation rel, Buffer leafbuf, BTStack stack)
17951789
nextoffset=OffsetNumberNext(poffset);
17961790
itemid=PageGetItemId(page,nextoffset);
17971791
itup= (IndexTuple)PageGetItem(page,itemid);
1792+
1793+
/*
1794+
* Check that the parent-page index items we're about to delete/overwrite
1795+
* in subtree parent page contain what we expect. This can fail if the
1796+
* index has become corrupt for some reason. When that happens we back
1797+
* out of deletion of the leafbuf subtree. (This is just like the case
1798+
* where _bt_lock_subtree_parent() cannot "re-find" leafbuf's downlink.)
1799+
*/
17981800
if (BTreeTupleGetDownLink(itup)!=topparentrightsib)
1799-
ereport(ERROR,
1801+
{
1802+
ereport(LOG,
18001803
(errcode(ERRCODE_INDEX_CORRUPTED),
18011804
errmsg_internal("right sibling %u of block %u is not next child %u of block %u in index \"%s\"",
18021805
topparentrightsib,topparent,
18031806
BTreeTupleGetDownLink(itup),
18041807
BufferGetBlockNumber(subtreeparent),
18051808
RelationGetRelationName(rel))));
18061809

1810+
_bt_relbuf(rel,subtreeparent);
1811+
Assert(false);
1812+
return false;
1813+
}
1814+
18071815
/*
18081816
* Any insert which would have gone on the leaf block will now go to its
18091817
* right sibling. In other words, the key space moves right.
@@ -2428,6 +2436,7 @@ _bt_lock_subtree_parent(Relation rel, BlockNumber child, BTStack stack,
24282436
(errcode(ERRCODE_INDEX_CORRUPTED),
24292437
errmsg_internal("failed to re-find parent key in index \"%s\" for deletion target page %u",
24302438
RelationGetRelationName(rel),child)));
2439+
Assert(false);
24312440
return false;
24322441
}
24332442

0 commit comments

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