| blob | 7f7b55d902a4c16b07f7f50d3a2c266f7762373c |
1 /*-------------------------------------------------------------------------
2 *
3 * verify_nbtree.c
4 * Verifies the integrity of nbtree indexes based on invariants.
5 *
6 * For B-Tree indexes, verification includes checking that each page in the
7 * target index has items in logical order as reported by an insertion scankey
8 * (the insertion scankey sort-wise NULL semantics are needed for
9 * verification).
10 *
11 * When index-to-heap verification is requested, a Bloom filter is used to
12 * fingerprint all tuples in the target index, as the index is traversed to
13 * verify its structure. A heap scan later uses Bloom filter probes to verify
14 * that every visible heap tuple has a matching index tuple.
15 *
16 *
17 * Copyright (c) 2017-2025, PostgreSQL Global Development Group
18 *
19 * IDENTIFICATION
20 * contrib/amcheck/verify_nbtree.c
21 *
22 *-------------------------------------------------------------------------
23 */
45 PG_MODULE_MAGIC;
47 /*
48 * A B-Tree cannot possibly have this many levels, since there must be one
49 * block per level, which is bound by the range of BlockNumber:
50 */
51 #define InvalidBtreeLevel ((uint32) InvalidBlockNumber)
52 #define BTreeTupleGetNKeyAtts(itup, rel) \
53 Min(IndexRelationGetNumberOfKeyAttributes(rel), BTreeTupleGetNAtts(itup, rel))
55 /*
56 * State associated with verifying a B-Tree index
57 *
58 * target is the point of reference for a verification operation.
59 *
60 * Other B-Tree pages may be allocated, but those are always auxiliary (e.g.,
61 * they are current target's child pages). Conceptually, problems are only
62 * ever found in the current target page (or for a particular heap tuple during
63 * heapallindexed verification). Each page found by verification's left/right,
64 * top/bottom scan becomes the target exactly once.
65 */
67 {
68 /*
69 * Unchanging state, established at start of verification:
70 */
72 /* B-Tree Index Relation and associated heap relation */
73 Relation rel;
74 Relation heaprel;
75 /* rel is heapkeyspace index? */
77 /* ShareLock held on heap/index, rather than AccessShareLock? */
79 /* Also verifying heap has no unindexed tuples? */
81 /* Also making sure non-pivot tuples can be found by new search? */
83 /* Also check uniqueness constraint if index is unique */
85 /* Per-page context */
86 MemoryContext targetcontext;
87 /* Buffer access strategy */
88 BufferAccessStrategy checkstrategy;
90 /*
91 * Info for uniqueness checking. Fill these fields once per index check.
92 */
94 Snapshot snapshot;
96 /*
97 * Mutable state, for verification of particular page:
98 */
100 /* Current target page */
101 Page target;
102 /* Target block number */
103 BlockNumber targetblock;
104 /* Target page's LSN */
105 XLogRecPtr targetlsn;
107 /*
108 * Low key: high key of left sibling of target page. Used only for child
109 * verification. So, 'lowkey' is kept only when 'readonly' is set.
110 */
111 IndexTuple lowkey;
113 /*
114 * The rightlink and incomplete split flag of block one level down to the
115 * target page, which was visited last time via downlink from target page.
116 * We use it to check for missing downlinks.
117 */
118 BlockNumber prevrightlink;
121 /*
122 * Mutable state, for optional heapallindexed verification:
123 */
125 /* Bloom filter fingerprints B-Tree index */
127 /* Debug counter */
128 int64 heaptuplespresent;
131 /*
132 * Starting point for verifying an entire B-Tree index level
133 */
135 {
136 /* Level number (0 is leaf page level). */
137 uint32 level;
139 /* Left most block on level. Scan of level begins here. */
140 BlockNumber leftmost;
142 /* Is this level reported as "true" root level by meta page? */
146 /*
147 * Information about the last visible entry with current B-tree key. Used
148 * for validation of the unique constraint.
149 */
151 {
155 * non-deduplicated tuples) */
171 BtreeLevel level);
173 BlockNumber start,
174 BTPageOpaque start_opaque);
176 BlockNumber btpo_prev_from_target,
177 BlockNumber leftcurrent);
181 ItemPointer nexttid,
191 OffsetNumber downlinkoffnum);
193 OffsetNumber target_downlinkoffnum,
194 Page loaded_child,
195 uint32 target_level);
202 IndexTuple itup);
206 OffsetNumber offset);
208 OffsetNumber upperbound);
210 BTScanInsert key,
211 OffsetNumber upperbound);
213 OffsetNumber lowerbound);
215 BTScanInsert key,
216 BlockNumber nontargetblock,
217 Page nontarget,
218 OffsetNumber upperbound);
221 IndexTuple itup);
228 /*
229 * bt_index_check(index regclass, heapallindexed boolean, checkunique boolean)
230 *
231 * Verify integrity of B-Tree index.
232 *
233 * Acquires AccessShareLock on heap & index relations. Does not consider
234 * invariants that exist between parent/child pages. Optionally verifies
235 * that heap does not contain any unindexed or incorrectly indexed tuples.
236 */
237 Datum
239 {
252 }
254 /*
255 * bt_index_parent_check(index regclass, heapallindexed boolean, rootdescend boolean, checkunique boolean)
256 *
257 * Verify integrity of B-Tree index.
258 *
259 * Acquires ShareLock on heap & index relations. Verifies that downlinks in
260 * parent pages are valid lower bounds on child pages. Optionally verifies
261 * that heap does not contain any unindexed or incorrectly indexed tuples.
262 */
263 Datum
265 {
281 }
283 /*
284 * Helper for bt_index_[parent_]check, coordinating the bulk of the work.
285 */
286 static void
289 {
290 Oid heapid;
291 Relation indrel;
292 Relation heaprel;
293 LOCKMODE lockmode;
294 Oid save_userid;
300 else
303 /*
304 * We must lock table before index to avoid deadlocks. However, if the
305 * passed indrelid isn't an index then IndexGetRelation() will fail.
306 * Rather than emitting a not-very-helpful error message, postpone
307 * complaining, expecting that the is-it-an-index test below will fail.
308 *
309 * In hot standby mode this will raise an error when parentcheck is true.
310 */
313 {
316 /*
317 * Switch to the table owner's userid, so that any index functions are
318 * run as that user. Also lock down security-restricted operations
319 * and arrange to make GUC variable changes local to this command.
320 */
326 }
327 else
328 {
330 /* Set these just to suppress "uninitialized variable" warnings */
334 }
336 /*
337 * Open the target index relations separately (like relation_openrv(), but
338 * with heap relation locked first to prevent deadlocking). In hot
339 * standby mode this will raise an error when parentcheck is true.
340 *
341 * There is no need for the usual indcheckxmin usability horizon test
342 * here, even in the heapallindexed case, because index undergoing
343 * verification only needs to have entries for a new transaction snapshot.
344 * (If this is a parentcheck verification, there is no question about
345 * committed or recently dead heap tuples lacking index entries due to
346 * concurrent activity.)
347 */
350 /*
351 * Since we did the IndexGetRelation call above without any lock, it's
352 * barely possible that a race against an index drop/recreation could have
353 * netted us the wrong table.
354 */
361 /* Relation suitable for checking as B-Tree? */
365 {
367 allequalimage;
375 /* Extract metadata from metapage, and sanitize it in passing */
383 {
393 has_interval_ops
396 }
398 /* Check index, possibly against table it is an index on */
401 }
403 /* Roll back any GUC changes executed by index functions */
406 /* Restore userid and security context */
409 /*
410 * Release locks early. That's ok here because nothing in the called
411 * routines will trigger shared cache invalidations to be sent, so we can
412 * relax the usual pattern of only releasing locks after commit.
413 */
417 }
419 /*
420 * Basic checks about the suitability of a relation for checking as a B-Tree
421 * index.
422 *
423 * NB: Intentionally not checking permissions, the function is normally not
424 * callable by non-superusers. If granted, it's useful to be able to check a
425 * whole cluster.
426 */
429 {
451 }
453 /*
454 * Check if B-Tree index relation should have a file for its main relation
455 * fork. Verification uses this to skip unlogged indexes when in hot standby
456 * mode, where there is simply nothing to verify. We behave as if the
457 * relation is empty.
458 *
459 * NB: Caller should call btree_index_checkable() before calling here.
460 */
463 {
474 }
476 /*
477 * Main entry point for B-Tree SQL-callable functions. Walks the B-Tree in
478 * logical order, verifying invariants as it goes. Optionally, verification
479 * checks if the heap relation contains any tuples that are not represented in
480 * the index but should be.
481 *
482 * It is the caller's responsibility to acquire appropriate heavyweight lock on
483 * the index relation, and advise us if extra checks are safe when a ShareLock
484 * is held. (A lock of the same type must also have been acquired on the heap
485 * relation.)
486 *
487 * A ShareLock is generally assumed to prevent any kind of physical
488 * modification to the index structure, including modifications that VACUUM may
489 * make. This does not include setting of the LP_DEAD bit by concurrent index
490 * scans, although that is just metadata that is not able to directly affect
491 * any check performed here. Any concurrent process that might act on the
492 * LP_DEAD bit being set (recycle space) requires a heavyweight lock that
493 * cannot be held while we hold a ShareLock. (Besides, even if that could
494 * happen, the ad-hoc recycling when a page might otherwise split is performed
495 * per-page, and requires an exclusive buffer lock, which wouldn't cause us
496 * trouble. _bt_delitems_vacuum() may only delete leaf items, and so the extra
497 * parent/child check cannot be affected.)
498 */
499 static void
503 {
505 Page metapage;
507 uint32 previouslevel;
508 BtreeLevel current;
514 else
515 elog(DEBUG1, "verifying consistency of tree structure for index \"%s\" with cross-level checks",
518 /*
519 * This assertion matches the one in index_getnext_tid(). See page
520 * recycling/"visible to everyone" notes in nbtree README.
521 */
524 /*
525 * Initialize state for entire verification operation
526 */
538 {
539 int64 total_pages;
540 int64 total_elems;
541 uint64 seed;
543 /*
544 * Size Bloom filter based on estimated number of tuples in index,
545 * while conservatively assuming that each block must contain at least
546 * MaxTIDsPerBTreePage / 3 "plain" tuples -- see
547 * bt_posting_plain_tuple() for definition, and details of how posting
548 * list tuples are handled.
549 */
553 /* Generate a random seed to avoid repetition */
555 /* Create Bloom filter to fingerprint index */
559 /*
560 * Register our own snapshot in !readonly case, rather than asking
561 * table_index_build_scan() to do this for us later. This needs to
562 * happen before index fingerprinting begins, so we can later be
563 * certain that index fingerprinting should have reached all tuples
564 * returned by table_index_build_scan().
565 */
567 {
570 /*
571 * GetTransactionSnapshot() always acquires a new MVCC snapshot in
572 * READ COMMITTED mode. A new snapshot is guaranteed to have all
573 * the entries it requires in the index.
574 *
575 * We must defend against the possibility that an old xact
576 * snapshot was returned at higher isolation levels when that
577 * snapshot is not safe for index scans of the target index. This
578 * is possible when the snapshot sees tuples that are before the
579 * index's indcheckxmin horizon. Throwing an error here should be
580 * very rare. It doesn't seem worth using a secondary snapshot to
581 * avoid this.
582 */
590 }
591 }
593 /*
594 * We need a snapshot to check the uniqueness of the index. For better
595 * performance take it once per index check. If snapshot already taken
596 * reuse it.
597 */
599 {
602 {
605 else
607 }
608 }
614 errmsg("cannot verify that tuples from index \"%s\" can each be found by an independent index search",
618 /* Create context for page */
621 ALLOCSET_DEFAULT_SIZES);
624 /* Get true root block from meta-page */
628 /*
629 * Certain deletion patterns can result in "skinny" B-Tree indexes, where
630 * the fast root and true root differ.
631 *
632 * Start from the true root, not the fast root, unlike conventional index
633 * scans. This approach is more thorough, and removes the risk of
634 * following a stale fast root from the meta page.
635 */
645 /*
646 * Starting at the root, verify every level. Move left to right, top to
647 * bottom. Note that there may be no pages other than the meta page (meta
648 * page can indicate that root is P_NONE when the index is totally empty).
649 */
655 {
656 /*
657 * Verify this level, and get left most page for next level down, if
658 * not at leaf level
659 */
669 }
671 /*
672 * * Check whether heap contains unindexed/malformed tuples *
673 */
675 {
677 TableScanDesc scan;
679 /*
680 * Create our own scan for table_index_build_scan(), rather than
681 * getting it to do so for us. This is required so that we can
682 * actually use the MVCC snapshot registered earlier in !readonly
683 * case.
684 *
685 * Note that table_index_build_scan() calls heap_endscan() for us.
686 */
694 /*
695 * Scan will behave as the first scan of a CREATE INDEX CONCURRENTLY
696 * behaves in !readonly case.
697 *
698 * It's okay that we don't actually use the same lock strength for the
699 * heap relation as any other ii_Concurrent caller would in !readonly
700 * case. We have no reason to care about a concurrent VACUUM
701 * operation, since there isn't going to be a second scan of the heap
702 * that needs to be sure that there was no concurrent recycling of
703 * TIDs.
704 */
707 /*
708 * Don't wait for uncommitted tuple xact commit/abort when index is a
709 * unique index on a catalog (or an index used by an exclusion
710 * constraint). This could otherwise happen in the readonly case.
711 */
725 (errmsg_internal("finished verifying presence of " INT64_FORMAT " tuples from table \"%s\" with bitset %.2f%% set",
733 }
735 /* Be tidy: */
739 }
741 /*
742 * Given a left-most block at some level, move right, verifying each page
743 * individually (with more verification across pages for "readonly"
744 * callers). Caller should pass the true root page as the leftmost initially,
745 * working their way down by passing what is returned for the last call here
746 * until level 0 (leaf page level) was reached.
747 *
748 * Returns state for next call, if any. This includes left-most block number
749 * one level lower that should be passed on next level/call, which is set to
750 * P_NONE on last call here (when leaf level is verified). Level numbers
751 * follow the nbtree convention: higher levels have higher numbers, because new
752 * levels are added only due to a root page split. Note that prior to the
753 * first root page split, the root is also a leaf page, so there is always a
754 * level 0 (leaf level), and it's always the last level processed.
755 *
756 * Note on memory management: State's per-page context is reset here, between
757 * each call to bt_target_page_check().
758 */
759 static BtreeLevel
761 {
762 /* State to establish early, concerning entire level */
763 BTPageOpaque opaque;
764 MemoryContext oldcontext;
765 BtreeLevel nextleveldown;
767 /* Variables for iterating across level using right links */
771 /* Initialize return state */
776 /* Use page-level context for duration of this call */
786 do
787 {
788 /* Don't rely on CHECK_FOR_INTERRUPTS() calls at lower level */
791 /* Initialize state for this iteration */
799 {
800 /*
801 * Since there cannot be a concurrent VACUUM operation in readonly
802 * mode, and since a page has no links within other pages
803 * (siblings and parent) once it is marked fully deleted, it
804 * should be impossible to land on a fully deleted page in
805 * readonly mode. See bt_child_check() for further details.
806 *
807 * The bt_child_check() P_ISDELETED() check is repeated here so
808 * that pages that are only reachable through sibling links get
809 * checked.
810 */
824 else
830 }
832 {
833 /*
834 * A concurrent page split could make the caller supplied leftmost
835 * block no longer contain the leftmost page, or no longer be the
836 * true root, but where that isn't possible due to heavyweight
837 * locking, check that the first valid page meets caller's
838 * expectations.
839 */
841 {
853 }
855 /*
856 * Before beginning any non-trivial examination of level, prepare
857 * state for next bt_check_level_from_leftmost() invocation for
858 * the next level for the next level down (if any).
859 *
860 * There should be at least one non-ignorable page per level,
861 * unless this is the leaf level, which is assumed by caller to be
862 * final level.
863 */
865 {
866 IndexTuple itup;
867 ItemId itemid;
869 /* Internal page -- downlink gets leftmost on next level */
876 }
877 else
878 {
879 /*
880 * Leaf page -- final level caller must process.
881 *
882 * Note that this could also be the root page, if there has
883 * been no root page split yet.
884 */
887 }
889 /*
890 * Finished setting up state for this call/level. Control will
891 * never end up back here in any future loop iteration for this
892 * level.
893 */
894 }
896 /*
897 * Sibling links should be in mutual agreement. There arises
898 * leftcurrent == P_NONE && btpo_prev != P_NONE when the left sibling
899 * of the parent's low-key downlink is half-dead. (A half-dead page
900 * has no downlink from its parent.) Under heavyweight locking, the
901 * last bt_leftmost_ignoring_half_dead() validated this btpo_prev.
902 * Without heavyweight locking, validation of the P_NONE case remains
903 * unimplemented.
904 */
908 /* Check level */
912 errmsg("leftmost down link for level points to block in index \"%s\" whose level is not one level down",
917 /* Verify invariants for page */
920 nextpage:
922 /* Try to detect circular links */
933 {
937 }
939 /*
940 * Copy current target high key as the low key of right sibling.
941 * Allocate memory in upper level context, so it would be cleared
942 * after reset of target context.
943 *
944 * We only need the low key in corner cases of checking child high
945 * keys. We use high key only when incomplete split on the child level
946 * falls to the boundary of pages on the target level. See
947 * bt_child_highkey_check() for details. So, typically we won't end
948 * up doing anything with low key, but it's simpler for general case
949 * high key verification to always have it available.
950 *
951 * The correctness of managing low key in the case of concurrent
952 * splits wasn't investigated yet. Thankfully we only need low key
953 * for readonly verification and concurrent splits won't happen.
954 */
956 {
957 IndexTuple itup;
958 ItemId itemid;
966 }
968 /* Free page and associated memory for this iteration */
970 }
974 {
978 }
980 /* Don't change context for caller */
984 }
986 /* Check visibility of the table entry referenced by nbtree index */
987 static bool
989 {
1000 }
1002 /*
1003 * Prepare an error message for unique constrain violation in
1004 * a btree index and report ERROR.
1005 */
1006 static void
1011 {
1043 }
1045 /* Check if current nbtree leaf entry complies with UNIQUE constraint */
1046 static void
1050 {
1051 ItemPointer tid;
1056 /*
1057 * Current tuple has posting list. Report duplicate if TID of any posting
1058 * list entry is visible and lVis->tid is valid.
1059 */
1061 {
1063 {
1066 {
1069 {
1071 lVis,
1074 }
1076 /*
1077 * Prevent double reporting unique constraint violation
1078 * between the posting list entries of the first tuple on the
1079 * page after cross-page check.
1080 */
1088 }
1089 }
1090 }
1092 /*
1093 * Current tuple has no posting list. If TID is visible save info about it
1094 * for the next comparisons in the loop in bt_target_page_check(). Report
1095 * duplicate if lVis->tid is already valid.
1096 */
1097 else
1098 {
1101 {
1104 {
1106 lVis,
1109 }
1115 }
1116 }
1121 {
1131 errdetail("It doesn't have visible heap tids and key is equal to the tid=(%u,%u)%s (points to heap tid=(%u,%u)).",
1136 }
1137 }
1139 /*
1140 * Like P_LEFTMOST(start_opaque), but accept an arbitrarily-long chain of
1141 * half-dead, sibling-linked pages to the left. If a half-dead page appears
1142 * under state->readonly, the database exited recovery between the first-stage
1143 * and second-stage WAL records of a deletion.
1144 */
1145 static bool
1147 BlockNumber start,
1148 BTPageOpaque start_opaque)
1149 {
1154 /*
1155 * To handle the !readonly case, we'd need to accept BTP_DELETED pages and
1156 * potentially observe nbtree/README "Page deletion and backwards scans".
1157 */
1161 {
1167 /*
1168 * Try to detect btpo_prev circular links. _bt_unlink_halfdead_page()
1169 * writes that side-links will continue to point to the siblings.
1170 * Check btpo_next for that property.
1171 */
1177 {
1180 /* pagelsn should point to an XLOG_BTREE_MARK_PAGE_HALFDEAD */
1191 }
1194 }
1197 }
1199 /*
1200 * Raise an error when target page's left link does not point back to the
1201 * previous target page, called leftcurrent here. The leftcurrent page's
1202 * right link was followed to get to the current target page, and we expect
1203 * mutual agreement among leftcurrent and the current target page. Make sure
1204 * that this condition has definitely been violated in the !readonly case,
1205 * where concurrent page splits are something that we need to deal with.
1206 *
1207 * Cross-page inconsistencies involving pages that don't agree about being
1208 * siblings are known to be a particularly good indicator of corruption
1209 * involving partial writes/lost updates. The bt_right_page_check_scankey
1210 * check also provides a way of detecting cross-page inconsistencies for
1211 * !readonly callers, but it can only detect sibling pages that have an
1212 * out-of-order keyspace, which can't catch many of the problems that we
1213 * expect to catch here.
1214 *
1215 * The classic example of the kind of inconsistency that we can only catch
1216 * with this check (when in !readonly mode) involves three sibling pages that
1217 * were affected by a faulty page split at some point in the past. The
1218 * effects of the split are reflected in the original page and its new right
1219 * sibling page, with a lack of any accompanying changes for the _original_
1220 * right sibling page. The original right sibling page's left link fails to
1221 * point to the new right sibling page (its left link still points to the
1222 * original page), even though the first phase of a page split is supposed to
1223 * work as a single atomic action. This subtle inconsistency will probably
1224 * only break backwards scans in practice.
1225 *
1226 * Note that this is the only place where amcheck will "couple" buffer locks
1227 * (and only for !readonly callers). In general we prefer to avoid more
1228 * thorough cross-page checks in !readonly mode, but it seems worth the
1229 * complexity here. Also, the performance overhead of performing lock
1230 * coupling here is negligible in practice. Control only reaches here with a
1231 * non-corrupt index when there is a concurrent page split at the instant
1232 * caller crossed over to target page from leftcurrent page.
1233 */
1234 static void
1236 BlockNumber btpo_prev_from_target,
1237 BlockNumber leftcurrent)
1238 {
1239 /* passing metapage to BTPageGetOpaque() would give irrelevant findings */
1243 {
1244 Buffer lbuf;
1245 Buffer newtargetbuf;
1246 Page page;
1247 BTPageOpaque opaque;
1248 BlockNumber newtargetblock;
1250 /* Couple locks in the usual order for nbtree: Left to right */
1258 {
1259 /*
1260 * Cannot reason about concurrently deleted page -- the left link
1261 * in the page to the right is expected to point to some other
1262 * page to the left (not leftcurrent page).
1263 *
1264 * Note that we deliberately don't give up with a half-dead page.
1265 */
1268 }
1271 /* Avoid self-deadlock when newtargetblock == leftcurrent */
1273 {
1281 /* btpo_prev_from_target may have changed; update it */
1283 }
1284 else
1285 {
1286 /*
1287 * leftcurrent right sibling points back to leftcurrent block.
1288 * Index is corrupt. Easiest way to handle this is to pretend
1289 * that we actually read from a distinct page that has an invalid
1290 * block number in its btpo_prev.
1291 */
1294 }
1296 /*
1297 * No need to check P_ISDELETED here, since new target block cannot be
1298 * marked deleted as long as we hold a lock on lbuf
1299 */
1305 {
1306 /* Report split in left sibling, not target (or new target) */
1315 }
1317 /*
1318 * Index is corrupt. Make sure that we report correct target page.
1319 *
1320 * This could have changed in cases where there was a concurrent page
1321 * split, as well as index corruption (at least in theory). Note that
1322 * btpo_prev_from_target was already updated above.
1323 */
1325 }
1333 btpo_prev_from_target)));
1334 }
1336 /*
1337 * Function performs the following checks on target page, or pages ancillary to
1338 * target page:
1339 *
1340 * - That every "real" data item is less than or equal to the high key, which
1341 * is an upper bound on the items on the page. Data items should be
1342 * strictly less than the high key when the page is an internal page.
1343 *
1344 * - That within the page, every data item is strictly less than the item
1345 * immediately to its right, if any (i.e., that the items are in order
1346 * within the page, so that the binary searches performed by index scans are
1347 * sane).
1348 *
1349 * - That the last data item stored on the page is strictly less than the
1350 * first data item on the page to the right (when such a first item is
1351 * available).
1352 *
1353 * - Various checks on the structure of tuples themselves. For example, check
1354 * that non-pivot tuples have no truncated attributes.
1355 *
1356 * - For index with unique constraint make sure that only one of table entries
1357 * for equal keys is visible.
1358 *
1359 * Furthermore, when state passed shows ShareLock held, function also checks:
1360 *
1361 * - That all child pages respect strict lower bound from parent's pivot
1362 * tuple.
1363 *
1364 * - That downlink to block was encountered in parent where that's expected.
1365 *
1366 * - That high keys of child pages matches corresponding pivot keys in parent.
1367 *
1368 * This is also where heapallindexed callers use their Bloom filter to
1369 * fingerprint IndexTuples for later table_index_build_scan() verification.
1370 *
1371 * Note: Memory allocated in this routine is expected to be released by caller
1372 * resetting state->targetcontext.
1373 */
1374 static void
1376 {
1377 OffsetNumber offset;
1378 OffsetNumber max;
1379 BTPageOpaque topaque;
1381 /* Last visible entry info for checking indexes with unique constraint */
1390 /*
1391 * Check the number of attributes in high key. Note, rightmost page
1392 * doesn't contain a high key, so nothing to check
1393 */
1395 {
1396 ItemId itemid;
1397 IndexTuple itup;
1399 /* Verify line pointer before checking tuple */
1403 P_HIKEY))
1404 {
1415 }
1416 }
1418 /*
1419 * Loop over page items, starting from first non-highkey item, not high
1420 * key (if any). Most tests are not performed for the "negative infinity"
1421 * real item (if any).
1422 */
1426 {
1427 ItemId itemid;
1428 IndexTuple itup;
1430 BTScanInsert skey;
1432 ItemPointer scantid;
1434 /*
1435 * True if we already called bt_entry_unique_check() for the current
1436 * item. This helps to avoid visiting the heap for keys, which are
1437 * anyway presented only once and can't comprise a unique violation.
1438 */
1448 /*
1449 * lp_len should match the IndexTuple reported length exactly, since
1450 * lp_len is completely redundant in indexes, and both sources of
1451 * tuple length are MAXALIGN()'d. nbtree does not use lp_len all that
1452 * frequently, and is surprisingly tolerant of corrupt lp_len fields.
1453 */
1465 /* Check the number of index tuple attributes */
1467 offset))
1468 {
1469 ItemPointer tid;
1484 itid,
1487 htid,
1489 }
1491 /*
1492 * Don't try to generate scankey using "negative infinity" item on
1493 * internal pages. They are always truncated to zero attributes.
1494 */
1496 {
1497 /*
1498 * We don't call bt_child_check() for "negative infinity" items.
1499 * But if we're performing downlink connectivity check, we do it
1500 * for every item including "negative infinity" one.
1501 */
1503 {
1505 offset,
1506 NULL,
1508 }
1510 }
1512 /*
1513 * Readonly callers may optionally verify that non-pivot tuples can
1514 * each be found by an independent search that starts from the root.
1515 * Note that we deliberately don't do individual searches for each
1516 * TID, since the posting list itself is validated by other checks.
1517 */
1520 {
1536 }
1538 /*
1539 * If tuple is a posting list tuple, make sure posting list TIDs are
1540 * in order
1541 */
1543 {
1544 ItemPointerData last;
1545 ItemPointer current;
1550 {
1555 {
1565 }
1568 }
1569 }
1571 /* Build insertion scankey for current page offset */
1574 /*
1575 * Make sure tuple size does not exceed the relevant BTREE_VERSION
1576 * specific limit.
1577 *
1578 * BTREE_VERSION 4 (which introduced heapkeyspace rules) requisitioned
1579 * a small amount of space from BTMaxItemSize() in order to ensure
1580 * that suffix truncation always has enough space to add an explicit
1581 * heap TID back to a tuple -- we pessimistically assume that every
1582 * newly inserted tuple will eventually need to have a heap TID
1583 * appended during a future leaf page split, when the tuple becomes
1584 * the basis of the new high key (pivot tuple) for the leaf page.
1585 *
1586 * Since the reclaimed space is reserved for that purpose, we must not
1587 * enforce the slightly lower limit when the extra space has been used
1588 * as intended. In other words, there is only a cross-version
1589 * difference in the limit on tuple size within leaf pages.
1590 *
1591 * Still, we're particular about the details within BTREE_VERSION 4
1592 * internal pages. Pivot tuples may only use the extra space for its
1593 * designated purpose. Enforce the lower limit for pivot tuples when
1594 * an explicit heap TID isn't actually present. (In all other cases
1595 * suffix truncation is guaranteed to generate a pivot tuple that's no
1596 * larger than the firstright tuple provided to it by its caller.)
1597 */
1602 {
1617 itid,
1619 htid,
1621 }
1623 /* Fingerprint leaf page tuples (those that point to the heap) */
1625 {
1626 IndexTuple norm;
1629 {
1630 /* Fingerprint all elements as distinct "plain" tuples */
1632 {
1633 IndexTuple logtuple;
1639 /* Be tidy */
1643 }
1644 }
1645 else
1646 {
1650 /* Be tidy */
1653 }
1654 }
1656 /*
1657 * * High key check *
1658 *
1659 * If there is a high key (if this is not the rightmost page on its
1660 * entire level), check that high key actually is upper bound on all
1661 * page items. If this is a posting list tuple, we'll need to set
1662 * scantid to be highest TID in posting list.
1663 *
1664 * We prefer to check all items against high key rather than checking
1665 * just the last and trusting that the operator class obeys the
1666 * transitive law (which implies that all previous items also
1667 * respected the high key invariant if they pass the item order
1668 * check).
1669 *
1670 * Ideally, we'd compare every item in the index against every other
1671 * item in the index, and not trust opclass obedience of the
1672 * transitive law to bridge the gap between children and their
1673 * grandparents (as well as great-grandparents, and so on). We don't
1674 * go to those lengths because that would be prohibitively expensive,
1675 * and probably not markedly more effective in practice.
1676 *
1677 * On the leaf level, we check that the key is <= the highkey.
1678 * However, on non-leaf levels we check that the key is < the highkey,
1679 * because the high key is "just another separator" rather than a copy
1680 * of some existing key item; we expect it to be unique among all keys
1681 * on the same level. (Suffix truncation will sometimes produce a
1682 * leaf highkey that is an untruncated copy of the lastleft item, but
1683 * never any other item, which necessitates weakening the leaf level
1684 * check to <=.)
1685 *
1686 * Full explanation for why a highkey is never truly a copy of another
1687 * item from the same level on internal levels:
1688 *
1689 * While the new left page's high key is copied from the first offset
1690 * on the right page during an internal page split, that's not the
1691 * full story. In effect, internal pages are split in the middle of
1692 * the firstright tuple, not between the would-be lastleft and
1693 * firstright tuples: the firstright key ends up on the left side as
1694 * left's new highkey, and the firstright downlink ends up on the
1695 * right side as right's new "negative infinity" item. The negative
1696 * infinity tuple is truncated to zero attributes, so we're only left
1697 * with the downlink. In other words, the copying is just an
1698 * implementation detail of splitting in the middle of a (pivot)
1699 * tuple. (See also: "Notes About Data Representation" in the nbtree
1700 * README.)
1701 */
1709 {
1724 itid,
1726 htid,
1728 }
1729 /* Reset, in case scantid was set to (itup) posting tuple's max TID */
1732 /*
1733 * * Item order check *
1734 *
1735 * Check that items are stored on page in logical order, by checking
1736 * current item is strictly less than next item (if any).
1737 */
1740 {
1741 ItemPointer tid;
1755 /* Reuse itup to get pointed-to heap location of second item */
1770 "higher index tid=%s (points to %s tid=%s) "
1772 itid,
1774 htid,
1775 nitid,
1777 nhtid,
1779 }
1781 /*
1782 * If the index is unique verify entries uniqueness by checking the
1783 * heap tuples visibility. Immediately check posting tuples and
1784 * tuples with repeated keys. Postpone check for keys, which have the
1785 * first appearance.
1786 */
1790 {
1794 }
1798 {
1799 /* Save current scankey tid */
1802 /*
1803 * Invalidate scankey tid to make _bt_compare compare only keys in
1804 * the item to report equality even if heap TIDs are different
1805 */
1808 /*
1809 * If next key tuple is different, invalidate last visible entry
1810 * data (whole index tuple or last posting in index tuple). Key
1811 * containing null value does not violate unique constraint and
1812 * treated as different to any other key.
1813 *
1814 * If the next key is the same as the previous one, do the
1815 * bt_entry_unique_check() call if it was postponed.
1816 */
1819 {
1824 }
1826 {
1829 }
1831 }
1833 /*
1834 * * Last item check *
1835 *
1836 * Check last item against next/right page's first data item's when
1837 * last item on page is reached. This additional check will detect
1838 * transposed pages iff the supposed right sibling page happens to
1839 * belong before target in the key space. (Otherwise, a subsequent
1840 * heap verification will probably detect the problem.)
1841 *
1842 * This check is similar to the item order check that will have
1843 * already been performed for every other "real" item on target page
1844 * when last item is checked. The difference is that the next item
1845 * (the item that is compared to target's last item) needs to come
1846 * from the next/sibling page. There may not be such an item
1847 * available from sibling for various reasons, though (e.g., target is
1848 * the rightmost page on level).
1849 */
1851 {
1852 BTScanInsert rightkey;
1854 /* first offset on a right index page (log only) */
1857 /* Get item in next/right page */
1862 {
1863 /*
1864 * As explained at length in bt_right_page_check_scankey(),
1865 * there is a known !readonly race that could account for
1866 * apparent violation of invariant, which we must check for
1867 * before actually proceeding with raising error. Our canary
1868 * condition is that target page was deleted.
1869 */
1871 {
1872 /* Get fresh copy of target page */
1874 /* Note that we deliberately do not update target LSN */
1877 /*
1878 * All !readonly checks now performed; just return
1879 */
1882 }
1891 }
1893 /*
1894 * If index has unique constraint make sure that no more than one
1895 * found equal items is visible.
1896 */
1899 {
1904 /*
1905 * Make _bt_compare compare only index keys without heap TIDs.
1906 * rightkey->scantid is modified destructively but it is ok
1907 * for it is not used later.
1908 */
1911 /* The first key on the next page is the same */
1914 {
1915 Page rightpage;
1917 /*
1918 * Do the bt_entry_unique_check() call if it was
1919 * postponed.
1920 */
1927 rightblock_number);
1931 {
1934 }
1946 rightpage,
1947 rightfirstoffset);
1953 }
1954 }
1955 }
1957 /*
1958 * * Downlink check *
1959 *
1960 * Additional check of child items iff this is an internal page and
1961 * caller holds a ShareLock. This happens for every downlink (item)
1962 * in target excluding the negative-infinity downlink (again, this is
1963 * because it has no useful value to compare).
1964 */
1967 }
1969 /*
1970 * Special case bt_child_highkey_check() call
1971 *
1972 * We don't pass a real downlink, but we've to finish the level
1973 * processing. If condition is satisfied, we've already processed all the
1974 * downlinks from the target level. But there still might be pages to the
1975 * right of the child page pointer to by our rightmost downlink. And they
1976 * might have missing downlinks. This final call checks for them.
1977 */
1979 {
1982 }
1983 }
1985 /*
1986 * Return a scankey for an item on page to right of current target (or the
1987 * first non-ignorable page), sufficient to check ordering invariant on last
1988 * item in current target page. Returned scankey relies on local memory
1989 * allocated for the child page, which caller cannot pfree(). Caller's memory
1990 * context should be reset between calls here.
1991 *
1992 * This is the first data item, and so all adjacent items are checked against
1993 * their immediate sibling item (which may be on a sibling page, or even a
1994 * "cousin" page at parent boundaries where target's rightlink points to page
1995 * with different parent page). If no such valid item is available, return
1996 * NULL instead.
1997 *
1998 * Note that !readonly callers must reverify that target page has not
1999 * been concurrently deleted.
2000 *
2001 * Save rightfirstoffset for detailed error message.
2002 */
2003 static BTScanInsert
2005 {
2006 BTPageOpaque opaque;
2007 ItemId rightitem;
2008 IndexTuple firstitup;
2009 BlockNumber targetnext;
2010 Page rightpage;
2011 OffsetNumber nline;
2013 /* Determine target's next block number */
2016 /* If target is already rightmost, no right sibling; nothing to do here */
2020 /*
2021 * General notes on concurrent page splits and page deletion:
2022 *
2023 * Routines like _bt_search() don't require *any* page split interlock
2024 * when descending the tree, including something very light like a buffer
2025 * pin. That's why it's okay that we don't either. This avoidance of any
2026 * need to "couple" buffer locks is the raison d' etre of the Lehman & Yao
2027 * algorithm, in fact.
2028 *
2029 * That leaves deletion. A deleted page won't actually be recycled by
2030 * VACUUM early enough for us to fail to at least follow its right link
2031 * (or left link, or downlink) and find its sibling, because recycling
2032 * does not occur until no possible index scan could land on the page.
2033 * Index scans can follow links with nothing more than their snapshot as
2034 * an interlock and be sure of at least that much. (See page
2035 * recycling/"visible to everyone" notes in nbtree README.)
2036 *
2037 * Furthermore, it's okay if we follow a rightlink and find a half-dead or
2038 * dead (ignorable) page one or more times. There will either be a
2039 * further right link to follow that leads to a live page before too long
2040 * (before passing by parent's rightmost child), or we will find the end
2041 * of the entire level instead (possible when parent page is itself the
2042 * rightmost on its level).
2043 */
2046 {
2055 /*
2056 * We landed on a deleted or half-dead sibling page. Step right until
2057 * we locate a live sibling page.
2058 */
2061 errmsg_internal("level %u sibling page in block %u of index \"%s\" was found deleted or half dead",
2067 /* Be slightly more pro-active in freeing this memory, just in case */
2069 }
2071 /*
2072 * No ShareLock held case -- why it's safe to proceed.
2073 *
2074 * Problem:
2075 *
2076 * We must avoid false positive reports of corruption when caller treats
2077 * item returned here as an upper bound on target's last item. In
2078 * general, false positives are disallowed. Avoiding them here when
2079 * caller is !readonly is subtle.
2080 *
2081 * A concurrent page deletion by VACUUM of the target page can result in
2082 * the insertion of items on to this right sibling page that would
2083 * previously have been inserted on our target page. There might have
2084 * been insertions that followed the target's downlink after it was made
2085 * to point to right sibling instead of target by page deletion's first
2086 * phase. The inserters insert items that would belong on target page.
2087 * This race is very tight, but it's possible. This is our only problem.
2088 *
2089 * Non-problems:
2090 *
2091 * We are not hindered by a concurrent page split of the target; we'll
2092 * never land on the second half of the page anyway. A concurrent split
2093 * of the right page will also not matter, because the first data item
2094 * remains the same within the left half, which we'll reliably land on. If
2095 * we had to skip over ignorable/deleted pages, it cannot matter because
2096 * their key space has already been atomically merged with the first
2097 * non-ignorable page we eventually find (doesn't matter whether the page
2098 * we eventually find is a true sibling or a cousin of target, which we go
2099 * into below).
2100 *
2101 * Solution:
2102 *
2103 * Caller knows that it should reverify that target is not ignorable
2104 * (half-dead or deleted) when cross-page sibling item comparison appears
2105 * to indicate corruption (invariant fails). This detects the single race
2106 * condition that exists for caller. This is correct because the
2107 * continued existence of target block as non-ignorable (not half-dead or
2108 * deleted) implies that target page was not merged into from the right by
2109 * deletion; the key space at or after target never moved left. Target's
2110 * parent either has the same downlink to target as before, or a <
2111 * downlink due to deletion at the left of target. Target either has the
2112 * same highkey as before, or a highkey < before when there is a page
2113 * split. (The rightmost concurrently-split-from-target-page page will
2114 * still have the same highkey as target was originally found to have,
2115 * which for our purposes is equivalent to target's highkey itself never
2116 * changing, since we reliably skip over
2117 * concurrently-split-from-target-page pages.)
2118 *
2119 * In simpler terms, we allow that the key space of the target may expand
2120 * left (the key space can move left on the left side of target only), but
2121 * the target key space cannot expand right and get ahead of us without
2122 * our detecting it. The key space of the target cannot shrink, unless it
2123 * shrinks to zero due to the deletion of the original page, our canary
2124 * condition. (To be very precise, we're a bit stricter than that because
2125 * it might just have been that the target page split and only the
2126 * original target page was deleted. We can be more strict, just not more
2127 * lax.)
2128 *
2129 * Top level tree walk caller moves on to next page (makes it the new
2130 * target) following recovery from this race. (cf. The rationale for
2131 * child/downlink verification needing a ShareLock within
2132 * bt_child_check(), where page deletion is also the main source of
2133 * trouble.)
2134 *
2135 * Note that it doesn't matter if right sibling page here is actually a
2136 * cousin page, because in order for the key space to be readjusted in a
2137 * way that causes us issues in next level up (guiding problematic
2138 * concurrent insertions to the cousin from the grandparent rather than to
2139 * the sibling from the parent), there'd have to be page deletion of
2140 * target's parent page (affecting target's parent's downlink in target's
2141 * grandparent page). Internal page deletion only occurs when there are
2142 * no child pages (they were all fully deleted), and caller is checking
2143 * that the target's parent has at least one non-deleted (so
2144 * non-ignorable) child: the target page. (Note that the first phase of
2145 * deletion atomically marks the page to be deleted half-dead/ignorable at
2146 * the same time downlink in its parent is removed, so caller will
2147 * definitely not fail to detect that this happened.)
2148 *
2149 * This trick is inspired by the method backward scans use for dealing
2150 * with concurrent page splits; concurrent page deletion is a problem that
2151 * similarly receives special consideration sometimes (it's possible that
2152 * the backwards scan will re-read its "original" block after failing to
2153 * find a right-link to it, having already moved in the opposite direction
2154 * (right/"forwards") a few times to try to locate one). Just like us,
2155 * that happens only to determine if there was a concurrent page deletion
2156 * of a reference page, and just like us if there was a page deletion of
2157 * that reference page it means we can move on from caring about the
2158 * reference page. See the nbtree README for a full description of how
2159 * that works.
2160 */
2163 /*
2164 * Get first data item, if any
2165 */
2167 {
2168 /* Return first data item (if any) */
2172 }
2175 {
2176 /*
2177 * Return first item after the internal page's "negative infinity"
2178 * item
2179 */
2182 }
2183 else
2184 {
2185 /*
2186 * No first item. Page is probably empty leaf page, but it's also
2187 * possible that it's an internal page with only a negative infinity
2188 * item.
2189 */
2196 }
2198 /*
2199 * Return first real item scankey. Note that this relies on right page
2200 * memory remaining allocated.
2201 */
2204 }
2206 /*
2207 * Check if two tuples are binary identical except the block number. So,
2208 * this function is capable to compare pivot keys on different levels.
2209 */
2210 static bool
2212 {
2217 {
2218 /*
2219 * Offset number will contain important information in heapkeyspace
2220 * indexes: the number of attributes left in the pivot tuple following
2221 * suffix truncation. Don't skip over it (compare it too).
2222 */
2227 }
2228 else
2229 {
2230 /*
2231 * Cannot rely on offset number field having consistent value across
2232 * levels on pg_upgrade'd !heapkeyspace indexes. Compare contents of
2233 * tuple starting from just after item pointer (i.e. after block
2234 * number and offset number).
2235 */
2240 }
2243 }
2245 /*---
2246 * Check high keys on the child level. Traverse rightlinks from previous
2247 * downlink to the current one. Check that there are no intermediate pages
2248 * with missing downlinks.
2249 *
2250 * If 'loaded_child' is given, it's assumed to be the page pointed to by the
2251 * downlink referenced by 'downlinkoffnum' of the target page.
2252 *
2253 * Basically this function is called for each target downlink and checks two
2254 * invariants:
2255 *
2256 * 1) You can reach the next child from previous one via rightlinks;
2257 * 2) Each child high key have matching pivot key on target level.
2258 *
2259 * Consider the sample tree picture.
2260 *
2261 * 1
2262 * / \
2263 * 2 <-> 3
2264 * / \ / \
2265 * 4 <> 5 <> 6 <> 7 <> 8
2266 *
2267 * This function will be called for blocks 4, 5, 6 and 8. Consider what is
2268 * happening for each function call.
2269 *
2270 * - The function call for block 4 initializes data structure and matches high
2271 * key of block 4 to downlink's pivot key of block 2.
2272 * - The high key of block 5 is matched to the high key of block 2.
2273 * - The block 6 has an incomplete split flag set, so its high key isn't
2274 * matched to anything.
2275 * - The function call for block 8 checks that block 8 can be found while
2276 * following rightlinks from block 6. The high key of block 7 will be
2277 * matched to downlink's pivot key in block 3.
2278 *
2279 * There is also final call of this function, which checks that there is no
2280 * missing downlinks for children to the right of the child referenced by
2281 * rightmost downlink in target level.
2282 */
2283 static void
2285 OffsetNumber target_downlinkoffnum,
2286 Page loaded_child,
2287 uint32 target_level)
2288 {
2290 Page page;
2291 BTPageOpaque opaque;
2294 ItemId itemid;
2295 IndexTuple itup;
2296 BlockNumber downlink;
2299 {
2304 }
2305 else
2306 {
2308 }
2310 /*
2311 * If no previous rightlink is memorized for current level just below
2312 * target page's level, we are about to start from the leftmost page. We
2313 * can't follow rightlinks from previous page, because there is no
2314 * previous page. But we still can match high key.
2315 *
2316 * So we initialize variables for the loop above like there is previous
2317 * page referencing current child. Also we imply previous page to not
2318 * have incomplete split flag, that would make us require downlink for
2319 * current child. That's correct, because leftmost page on the level
2320 * should always have parent downlink.
2321 */
2323 {
2326 }
2328 /* Move to the right on the child level */
2330 {
2331 /*
2332 * Did we traverse the whole tree level and this is check for pages to
2333 * the right of rightmost downlink?
2334 */
2336 {
2340 }
2342 /* Did we traverse the whole tree level and don't find next downlink? */
2350 /* Load page contents */
2353 else
2358 /* The first page we visit at the level should be leftmost */
2369 /* Do level sanity check */
2379 /* Try to detect circular links */
2387 {
2388 /* blkno probably has missing parent downlink */
2390 }
2394 /*
2395 * If we visit page with high key, check that it is equal to the
2396 * target key next to corresponding downlink.
2397 */
2399 {
2400 BTPageOpaque topaque;
2401 IndexTuple highkey;
2402 OffsetNumber pivotkey_offset;
2404 /* Get high key */
2408 /*
2409 * There might be two situations when we examine high key. If
2410 * current child page is referenced by given target downlink, we
2411 * should look to the next offset number for matching key from
2412 * target page.
2413 *
2414 * Alternatively, we're following rightlinks somewhere in the
2415 * middle between page referenced by previous target's downlink
2416 * and the page referenced by current target's downlink. If
2417 * current child page hasn't incomplete split flag set, then its
2418 * high key should match to the target's key of current offset
2419 * number. This happens when a previous call here (to
2420 * bt_child_highkey_check()) found an incomplete split, and we
2421 * reach a right sibling page without a downlink -- the right
2422 * sibling page's high key still needs to be matched to a
2423 * separator key on the parent/target level.
2424 *
2425 * Don't apply OffsetNumberNext() to target_downlinkoffnum when we
2426 * already had to step right on the child level. Our traversal of
2427 * the child level must try to move in perfect lockstep behind (to
2428 * the left of) the target/parent level traversal.
2429 */
2432 else
2438 {
2439 /*
2440 * If we're looking for the next pivot tuple in target page,
2441 * but there is no more pivot tuples, then we should match to
2442 * high key instead.
2443 */
2445 {
2455 }
2459 }
2460 else
2461 {
2462 /*
2463 * We cannot try to match child's high key to a negative
2464 * infinity key in target, since there is nothing to compare.
2465 * However, it's still possible to match child's high key
2466 * outside of target page. The reason why we're are is that
2467 * bt_child_highkey_check() was previously called for the
2468 * cousin page of 'loaded_child', which is incomplete split.
2469 * So, now we traverse to the right of that cousin page and
2470 * current child level page under consideration still belongs
2471 * to the subtree of target's left sibling. Thus, we need to
2472 * match child's high key to it's left uncle page high key.
2473 * Thankfully we saved it, it's called a "low key" of target
2474 * page.
2475 */
2485 }
2488 {
2496 }
2497 }
2499 /* Exit if we already found next downlink */
2501 {
2505 }
2507 /* Traverse to the next page using rightlink */
2510 /* Free page contents if it's allocated by us */
2514 }
2515 }
2517 /*
2518 * Checks one of target's downlink against its child page.
2519 *
2520 * Conceptually, the target page continues to be what is checked here. The
2521 * target block is still blamed in the event of finding an invariant violation.
2522 * The downlink insertion into the target is probably where any problem raised
2523 * here arises, and there is no such thing as a parent link, so doing the
2524 * verification this way around is much more practical.
2525 *
2526 * This function visits child page and it's sequentially called for each
2527 * downlink of target page. Assuming this we also check downlink connectivity
2528 * here in order to save child page visits.
2529 */
2530 static void
2532 OffsetNumber downlinkoffnum)
2533 {
2534 ItemId itemid;
2535 IndexTuple itup;
2536 BlockNumber childblock;
2537 OffsetNumber offset;
2538 OffsetNumber maxoffset;
2539 Page child;
2540 BTPageOpaque copaque;
2541 BTPageOpaque topaque;
2548 /*
2549 * Caller must have ShareLock on target relation, because of
2550 * considerations around page deletion by VACUUM.
2551 *
2552 * NB: In general, page deletion deletes the right sibling's downlink, not
2553 * the downlink of the page being deleted; the deleted page's downlink is
2554 * reused for its sibling. The key space is thereby consolidated between
2555 * the deleted page and its right sibling. (We cannot delete a parent
2556 * page's rightmost child unless it is the last child page, and we intend
2557 * to also delete the parent itself.)
2558 *
2559 * If this verification happened without a ShareLock, the following race
2560 * condition could cause false positives:
2561 *
2562 * In general, concurrent page deletion might occur, including deletion of
2563 * the left sibling of the child page that is examined here. If such a
2564 * page deletion were to occur, closely followed by an insertion into the
2565 * newly expanded key space of the child, a window for the false positive
2566 * opens up: the stale parent/target downlink originally followed to get
2567 * to the child legitimately ceases to be a lower bound on all items in
2568 * the page, since the key space was concurrently expanded "left".
2569 * (Insertion followed the "new" downlink for the child, not our now-stale
2570 * downlink, which was concurrently physically removed in target/parent as
2571 * part of deletion's first phase.)
2572 *
2573 * While we use various techniques elsewhere to perform cross-page
2574 * verification for !readonly callers, a similar trick seems difficult
2575 * here. The tricks used by bt_recheck_sibling_links and by
2576 * bt_right_page_check_scankey both involve verification of a same-level,
2577 * cross-sibling invariant. Cross-level invariants are far more squishy,
2578 * though. The nbtree REDO routines do not actually couple buffer locks
2579 * across levels during page splits, so making any cross-level check work
2580 * reliably in !readonly mode may be impossible.
2581 */
2584 /*
2585 * Verify child page has the downlink key from target page (its parent) as
2586 * a lower bound; downlink must be strictly less than all keys on the
2587 * page.
2588 *
2589 * Check all items, rather than checking just the first and trusting that
2590 * the operator class obeys the transitive law.
2591 */
2597 /*
2598 * Since we've already loaded the child block, combine this check with
2599 * check for downlink connectivity.
2600 */
2604 /*
2605 * Since there cannot be a concurrent VACUUM operation in readonly mode,
2606 * and since a page has no links within other pages (siblings and parent)
2607 * once it is marked fully deleted, it should be impossible to land on a
2608 * fully deleted page.
2609 *
2610 * It does not quite make sense to enforce that the page cannot even be
2611 * half-dead, despite the fact the downlink is modified at the same stage
2612 * that the child leaf page is marked half-dead. That's incorrect because
2613 * there may occasionally be multiple downlinks from a chain of pages
2614 * undergoing deletion, where multiple successive calls are made to
2615 * _bt_unlink_halfdead_page() by VACUUM before it can finally safely mark
2616 * the leaf page as fully dead. While _bt_mark_page_halfdead() usually
2617 * removes the downlink to the leaf page that is marked half-dead, that's
2618 * not guaranteed, so it's possible we'll land on a half-dead page with a
2619 * downlink due to an interrupted multi-level page deletion.
2620 *
2621 * We go ahead with our checks if the child page is half-dead. It's safe
2622 * to do so because we do not test the child's high key, so it does not
2623 * matter that the original high key will have been replaced by a dummy
2624 * truncated high key within _bt_mark_page_halfdead(). All other page
2625 * items are left intact on a half-dead page, so there is still something
2626 * to test.
2627 */
2640 {
2641 /*
2642 * Skip comparison of target page key against "negative infinity"
2643 * item, if any. Checking it would indicate that it's not a strict
2644 * lower bound, but that's only because of the hard-coding for
2645 * negative infinity items within _bt_compare().
2646 *
2647 * If nbtree didn't truncate negative infinity tuples during internal
2648 * page splits then we'd expect child's negative infinity key to be
2649 * equal to the scankey/downlink from target/parent (it would be a
2650 * "low key" in this hypothetical scenario, and so it would still need
2651 * to be treated as a special case here).
2652 *
2653 * Negative infinity items can be thought of as a strict lower bound
2654 * that works transitively, with the last non-negative-infinity pivot
2655 * followed during a descent from the root as its "true" strict lower
2656 * bound. Only a small number of negative infinity items are truly
2657 * negative infinity; those that are the first items of leftmost
2658 * internal pages. In more general terms, a negative infinity item is
2659 * only negative infinity with respect to the subtree that the page is
2660 * at the root of.
2661 *
2662 * See also: bt_rootdescend(), which can even detect transitive
2663 * inconsistencies on cousin leaf pages.
2664 */
2669 offset))
2677 }
2680 }
2682 /*
2683 * Checks if page is missing a downlink that it should have.
2684 *
2685 * A page that lacks a downlink/parent may indicate corruption. However, we
2686 * must account for the fact that a missing downlink can occasionally be
2687 * encountered in a non-corrupt index. This can be due to an interrupted page
2688 * split, or an interrupted multi-level page deletion (i.e. there was a hard
2689 * crash or an error during a page split, or while VACUUM was deleting a
2690 * multi-level chain of pages).
2691 *
2692 * Note that this can only be called in readonly mode, so there is no need to
2693 * be concerned about concurrent page splits or page deletions.
2694 */
2695 static void
2698 {
2700 ItemId itemid;
2701 IndexTuple itup;
2702 Page child;
2703 BTPageOpaque copaque;
2704 uint32 level;
2705 BlockNumber childblk;
2706 XLogRecPtr pagelsn;
2711 /* No next level up with downlinks to fingerprint from the true root */
2717 /*
2718 * Incomplete (interrupted) page splits can account for the lack of a
2719 * downlink. Some inserting transaction should eventually complete the
2720 * page split in passing, when it notices that the left sibling page is
2721 * P_INCOMPLETE_SPLIT().
2722 *
2723 * In general, VACUUM is not prepared for there to be no downlink to a
2724 * page that it deletes. This is the main reason why the lack of a
2725 * downlink can be reported as corruption here. It's not obvious that an
2726 * invalid missing downlink can result in wrong answers to queries,
2727 * though, since index scans that land on the child may end up
2728 * consistently moving right. The handling of concurrent page splits (and
2729 * page deletions) within _bt_moveright() cannot distinguish
2730 * inconsistencies that last for a moment from inconsistencies that are
2731 * permanent and irrecoverable.
2732 *
2733 * VACUUM isn't even prepared to delete pages that have no downlink due to
2734 * an incomplete page split, but it can detect and reason about that case
2735 * by design, so it shouldn't be taken to indicate corruption. See
2736 * _bt_pagedel() for full details.
2737 */
2739 {
2749 }
2751 /*
2752 * Page under check is probably the "top parent" of a multi-level page
2753 * deletion. We'll need to descend the subtree to make sure that
2754 * descendant pages are consistent with that, though.
2755 *
2756 * If the page (which must be non-ignorable) is a leaf page, then clearly
2757 * it can't be the top parent. The lack of a downlink is probably a
2758 * symptom of a broad problem that could just as easily cause
2759 * inconsistencies anywhere else.
2760 */
2767 blkno,
2770 /* Descend from the given page, which is an internal page */
2771 elog(DEBUG1, "checking for interrupted multi-level deletion due to missing downlink in index \"%s\"",
2779 {
2788 /* Do an extra sanity check in passing on internal pages */
2794 errdetail_internal("Top parent/under check block=%u block pointed to=%u expected level=%u level in pointed to block=%u.",
2803 /* Be slightly more pro-active in freeing this memory, just in case */
2805 }
2807 /*
2808 * Since there cannot be a concurrent VACUUM operation in readonly mode,
2809 * and since a page has no links within other pages (siblings and parent)
2810 * once it is marked fully deleted, it should be impossible to land on a
2811 * fully deleted page. See bt_child_check() for further details.
2812 *
2813 * The bt_child_check() P_ISDELETED() check is repeated here because
2814 * bt_child_check() does not visit pages reachable through negative
2815 * infinity items. Besides, bt_child_check() is unwilling to descend
2816 * multiple levels. (The similar bt_child_check() P_ISDELETED() check
2817 * within bt_check_level_from_leftmost() won't reach the page either,
2818 * since the leaf's live siblings should have their sibling links updated
2819 * to bypass the deletion target page when it is marked fully dead.)
2820 *
2821 * If this error is raised, it might be due to a previous multi-level page
2822 * deletion that failed to realize that it wasn't yet safe to mark the
2823 * leaf page as fully dead. A "dangling downlink" will still remain when
2824 * this happens. The fact that the dangling downlink's page (the leaf's
2825 * parent/ancestor page) lacked a downlink is incidental.
2826 */
2832 errdetail_internal("Top parent/target block=%u leaf block=%u top parent/under check lsn=%X/%X.",
2836 /*
2837 * Iff leaf page is half-dead, its high key top parent link should point
2838 * to what VACUUM considered to be the top parent page at the instant it
2839 * was interrupted. Provided the high key link actually points to the
2840 * page under check, the missing downlink we detected is consistent with
2841 * there having been an interrupted multi-level page deletion. This means
2842 * that the subtree with the page under check at its root (a page deletion
2843 * chain) is in a consistent state, enabling VACUUM to resume deleting the
2844 * entire chain the next time it encounters the half-dead leaf page.
2845 */
2847 {
2852 }
2861 }
2863 /*
2864 * Per-tuple callback from table_index_build_scan, used to determine if index has
2865 * all the entries that definitely should have been observed in leaf pages of
2866 * the target index (that is, all IndexTuples that were fingerprinted by our
2867 * Bloom filter). All heapallindexed checks occur here.
2868 *
2869 * The redundancy between an index and the table it indexes provides a good
2870 * opportunity to detect corruption, especially corruption within the table.
2871 * The high level principle behind the verification performed here is that any
2872 * IndexTuple that should be in an index following a fresh CREATE INDEX (based
2873 * on the same index definition) should also have been in the original,
2874 * existing index, which should have used exactly the same representation
2875 *
2876 * Since the overall structure of the index has already been verified, the most
2877 * likely explanation for error here is a corrupt heap page (could be logical
2878 * or physical corruption). Index corruption may still be detected here,
2879 * though. Only readonly callers will have verified that left links and right
2880 * links are in agreement, and so it's possible that a leaf page transposition
2881 * within index is actually the source of corruption detected here (for
2882 * !readonly callers). The checks performed only for readonly callers might
2883 * more accurately frame the problem as a cross-page invariant issue (this
2884 * could even be due to recovery not replaying all WAL records). The !readonly
2885 * ERROR message raised here includes a HINT about retrying with readonly
2886 * verification, just in case it's a cross-page invariant issue, though that
2887 * isn't particularly likely.
2888 *
2889 * table_index_build_scan() expects to be able to find the root tuple when a
2890 * heap-only tuple (the live tuple at the end of some HOT chain) needs to be
2891 * indexed, in order to replace the actual tuple's TID with the root tuple's
2892 * TID (which is what we're actually passed back here). The index build heap
2893 * scan code will raise an error when a tuple that claims to be the root of the
2894 * heap-only tuple's HOT chain cannot be located. This catches cases where the
2895 * original root item offset/root tuple for a HOT chain indicates (for whatever
2896 * reason) that the entire HOT chain is dead, despite the fact that the latest
2897 * heap-only tuple should be indexed. When this happens, sequential scans may
2898 * always give correct answers, and all indexes may be considered structurally
2899 * consistent (i.e. the nbtree structural checks would not detect corruption).
2900 * It may be the case that only index scans give wrong answers, and yet heap or
2901 * SLRU corruption is the real culprit. (While it's true that LP_DEAD bit
2902 * setting will probably also leave the index in a corrupt state before too
2903 * long, the problem is nonetheless that there is heap corruption.)
2904 *
2905 * Heap-only tuple handling within table_index_build_scan() works in a way that
2906 * helps us to detect index tuples that contain the wrong values (values that
2907 * don't match the latest tuple in the HOT chain). This can happen when there
2908 * is no superseding index tuple due to a faulty assessment of HOT safety,
2909 * perhaps during the original CREATE INDEX. Because the latest tuple's
2910 * contents are used with the root TID, an error will be raised when a tuple
2911 * with the same TID but non-matching attribute values is passed back to us.
2912 * Faulty assessment of HOT-safety was behind at least two distinct CREATE
2913 * INDEX CONCURRENTLY bugs that made it into stable releases, one of which was
2914 * undetected for many years. In short, the same principle that allows a
2915 * REINDEX to repair corruption when there was an (undetected) broken HOT chain
2916 * also allows us to detect the corruption in many cases.
2917 */
2918 static void
2921 {
2923 IndexTuple itup,
2924 norm;
2928 /* Generate a normalized index tuple for fingerprinting */
2933 /* Probe Bloom filter -- tuple should be present */
2944 ? errhint("Retrying verification using the function bt_index_parent_check() might provide a more specific error.")
2949 /* Cannot leak memory here */
2952 }
2954 /*
2955 * Normalize an index tuple for fingerprinting.
2956 *
2957 * In general, index tuple formation is assumed to be deterministic by
2958 * heapallindexed verification, and IndexTuples are assumed immutable. While
2959 * the LP_DEAD bit is mutable in leaf pages, that's ItemId metadata, which is
2960 * not fingerprinted. Normalization is required to compensate for corner
2961 * cases where the determinism assumption doesn't quite work.
2962 *
2963 * There is currently one such case: index_form_tuple() does not try to hide
2964 * the source TOAST state of input datums. The executor applies TOAST
2965 * compression for heap tuples based on different criteria to the compression
2966 * applied within btinsert()'s call to index_form_tuple(): it sometimes
2967 * compresses more aggressively, resulting in compressed heap tuple datums but
2968 * uncompressed corresponding index tuple datums. A subsequent heapallindexed
2969 * verification will get a logically equivalent though bitwise unequal tuple
2970 * from index_form_tuple(). False positive heapallindexed corruption reports
2971 * could occur without normalizing away the inconsistency.
2972 *
2973 * Returned tuple is often caller's own original tuple. Otherwise, it is a
2974 * new representation of caller's original index tuple, palloc()'d in caller's
2975 * memory context.
2976 *
2977 * Note: This routine is not concerned with distinctions about the
2978 * representation of tuples beyond those that might break heapallindexed
2979 * verification. In particular, it won't try to normalize opclass-equal
2980 * datums with potentially distinct representations (e.g., btree/numeric_ops
2981 * index datums will not get their display scale normalized-away here).
2982 * Caller does normalization for non-pivot tuples that have a posting list,
2983 * since dummy CREATE INDEX callback code generates new tuples with the same
2984 * normalized representation.
2985 */
2986 static IndexTuple
2988 {
2994 IndexTuple reformed;
2997 /* Caller should only pass "logical" non-pivot tuples here */
3000 /* Easy case: It's immediately clear that tuple has no varlena datums */
3005 {
3006 Form_pg_attribute att;
3010 /* Assume untoasted/already normalized datum initially */
3013 tupleDescriptor,
3018 /*
3019 * Callers always pass a tuple that could safely be inserted into the
3020 * index without further processing, so an external varlena header
3021 * should never be encountered here
3022 */
3034 {
3035 /*
3036 * This value will be compressed by index_form_tuple() with the
3037 * current storage settings. We may be here because this tuple
3038 * was formed with different storage settings. So, force forming.
3039 */
3041 }
3043 {
3047 }
3049 /*
3050 * Short tuples may have 1B or 4B header. Convert 4B header of short
3051 * tuples to 1B
3052 */
3054 {
3055 /* convert to short varlena */
3065 }
3066 }
3068 /*
3069 * Easier case: Tuple has varlena datums, none of which are compressed or
3070 * short with 4B header
3071 */
3075 /*
3076 * Hard case: Tuple had compressed varlena datums that necessitate
3077 * creating normalized version of the tuple from uncompressed input datums
3078 * (normalized input datums). This is rather naive, but shouldn't be
3079 * necessary too often.
3080 *
3081 * In the heap, tuples may contain short varlena datums with both 1B
3082 * header and 4B headers. But the corresponding index tuple should always
3083 * have such varlena's with 1B headers. So, if there is a short varlena
3084 * with 4B header, we need to convert it for fingerprinting.
3085 *
3086 * Note that we rely on deterministic index_form_tuple() TOAST compression
3087 * of normalized input.
3088 */
3092 /* Cannot leak memory here */
3098 }
3100 /*
3101 * Produce palloc()'d "plain" tuple for nth posting list entry/TID.
3102 *
3103 * In general, deduplication is not supposed to change the logical contents of
3104 * an index. Multiple index tuples are merged together into one equivalent
3105 * posting list index tuple when convenient.
3106 *
3107 * heapallindexed verification must normalize-away this variation in
3108 * representation by converting posting list tuples into two or more "plain"
3109 * tuples. Each tuple must be fingerprinted separately -- there must be one
3110 * tuple for each corresponding Bloom filter probe during the heap scan.
3111 *
3112 * Note: Caller still needs to call bt_normalize_tuple() with returned tuple.
3113 */
3116 {
3119 /* Returns non-posting-list tuple */
3121 }
3123 /*
3124 * Search for itup in index, starting from fast root page. itup must be a
3125 * non-pivot tuple. This is only supported with heapkeyspace indexes, since
3126 * we rely on having fully unique keys to find a match with only a single
3127 * visit to a leaf page, barring an interrupted page split, where we may have
3128 * to move right. (A concurrent page split is impossible because caller must
3129 * be readonly caller.)
3130 *
3131 * This routine can detect very subtle transitive consistency issues across
3132 * more than one level of the tree. Leaf pages all have a high key (even the
3133 * rightmost page has a conceptual positive infinity high key), but not a low
3134 * key. Their downlink in parent is a lower bound, which along with the high
3135 * key is almost enough to detect every possible inconsistency. A downlink
3136 * separator key value won't always be available from parent, though, because
3137 * the first items of internal pages are negative infinity items, truncated
3138 * down to zero attributes during internal page splits. While it's true that
3139 * bt_child_check() and the high key check can detect most imaginable key
3140 * space problems, there are remaining problems it won't detect with non-pivot
3141 * tuples in cousin leaf pages. Starting a search from the root for every
3142 * existing leaf tuple detects small inconsistencies in upper levels of the
3143 * tree that cannot be detected any other way. (Besides all this, this is
3144 * probably also useful as a direct test of the code used by index scans
3145 * themselves.)
3146 */
3147 static bool
3149 {
3150 BTScanInsert key;
3151 BTStack stack;
3152 Buffer lbuf;
3158 /*
3159 * Search from root.
3160 *
3161 * Ideally, we would arrange to only move right within _bt_search() when
3162 * an interrupted page split is detected (i.e. when the incomplete split
3163 * bit is found to be set), but for now we accept the possibility that
3164 * that could conceal an inconsistency.
3165 */
3171 {
3172 BTInsertStateData insertstate;
3173 OffsetNumber offnum;
3174 Page page;
3183 /* Get matching tuple on leaf page */
3185 /* Compare first >= matching item on leaf page, if any */
3187 /* Should match on first heap TID when tuple has a posting list */
3193 }
3199 }
3201 /*
3202 * Is particular offset within page (whose special state is passed by caller)
3203 * the page negative-infinity item?
3204 *
3205 * As noted in comments above _bt_compare(), there is special handling of the
3206 * first data item as a "negative infinity" item. The hard-coding within
3207 * _bt_compare() makes comparing this item for the purposes of verification
3208 * pointless at best, since the IndexTuple only contains a valid TID (a
3209 * reference TID to child page).
3210 */
3213 {
3214 /*
3215 * For internal pages only, the first item after high key, if any, is
3216 * negative infinity item. Internal pages always have a negative infinity
3217 * item, whereas leaf pages never have one. This implies that negative
3218 * infinity item is either first or second line item, or there is none
3219 * within page.
3220 *
3221 * Negative infinity items are a special case among pivot tuples. They
3222 * always have zero attributes, while all other pivot tuples always have
3223 * nkeyatts attributes.
3224 *
3225 * Right-most pages don't have a high key, but could be said to
3226 * conceptually have a "positive infinity" high key. Thus, there is a
3227 * symmetry between down link items in parent pages, and high keys in
3228 * children. Together, they represent the part of the key space that
3229 * belongs to each page in the index. For example, all children of the
3230 * root page will have negative infinity as a lower bound from root
3231 * negative infinity downlink, and positive infinity as an upper bound
3232 * (implicitly, from "imaginary" positive infinity high key in root).
3233 */
3235 }
3237 /*
3238 * Does the invariant hold that the key is strictly less than a given upper
3239 * bound offset item?
3240 *
3241 * Verifies line pointer on behalf of caller.
3242 *
3243 * If this function returns false, convention is that caller throws error due
3244 * to corruption.
3245 */
3248 OffsetNumber upperbound)
3249 {
3250 ItemId itemid;
3251 int32 cmp;
3255 /* Verify line pointer before checking tuple */
3257 upperbound);
3258 /* pg_upgrade'd indexes may legally have equal sibling tuples */
3264 /*
3265 * _bt_compare() is capable of determining that a scankey with a
3266 * filled-out attribute is greater than pivot tuples where the comparison
3267 * is resolved at a truncated attribute (value of attribute in pivot is
3268 * minus infinity). However, it is not capable of determining that a
3269 * scankey is _less than_ a tuple on the basis of a comparison resolved at
3270 * _scankey_ minus infinity attribute. Complete an extra step to simulate
3271 * having minus infinity values for omitted scankey attribute(s).
3272 */
3274 {
3275 BTPageOpaque topaque;
3276 IndexTuple ritup;
3278 ItemPointer rheaptid;
3285 /* Get number of keys + heap TID for item to the right */
3289 /* Heap TID is tiebreaker key attribute */
3294 }
3297 }
3299 /*
3300 * Does the invariant hold that the key is less than or equal to a given upper
3301 * bound offset item?
3302 *
3303 * Caller should have verified that upperbound's line pointer is consistent
3304 * using PageGetItemIdCareful() call.
3305 *
3306 * If this function returns false, convention is that caller throws error due
3307 * to corruption.
3308 */
3311 OffsetNumber upperbound)
3312 {
3313 int32 cmp;
3320 }
3322 /*
3323 * Does the invariant hold that the key is strictly greater than a given lower
3324 * bound offset item?
3325 *
3326 * Caller should have verified that lowerbound's line pointer is consistent
3327 * using PageGetItemIdCareful() call.
3328 *
3329 * If this function returns false, convention is that caller throws error due
3330 * to corruption.
3331 */
3334 OffsetNumber lowerbound)
3335 {
3336 int32 cmp;
3342 /* pg_upgrade'd indexes may legally have equal sibling tuples */
3346 /*
3347 * No need to consider the possibility that scankey has attributes that we
3348 * need to force to be interpreted as negative infinity. _bt_compare() is
3349 * able to determine that scankey is greater than negative infinity. The
3350 * distinction between "==" and "<" isn't interesting here, since
3351 * corruption is indicated either way.
3352 */
3354 }
3356 /*
3357 * Does the invariant hold that the key is strictly less than a given upper
3358 * bound offset item, with the offset relating to a caller-supplied page that
3359 * is not the current target page?
3360 *
3361 * Caller's non-target page is a child page of the target, checked as part of
3362 * checking a property of the target page (i.e. the key comes from the
3363 * target). Verifies line pointer on behalf of caller.
3364 *
3365 * If this function returns false, convention is that caller throws error due
3366 * to corruption.
3367 */
3371 OffsetNumber upperbound)
3372 {
3373 ItemId itemid;
3374 int32 cmp;
3378 /* Verify line pointer before checking tuple */
3380 upperbound);
3383 /* pg_upgrade'd indexes may legally have equal sibling tuples */
3387 /* See invariant_l_offset() for an explanation of this extra step */
3389 {
3390 IndexTuple child;
3392 ItemPointer childheaptid;
3393 BTPageOpaque copaque;
3400 /* Get number of keys + heap TID for child/non-target item */
3404 /* Heap TID is tiebreaker key attribute */
3409 }
3412 }
3414 /*
3415 * Given a block number of a B-Tree page, return page in palloc()'d memory.
3416 * While at it, perform some basic checks of the page.
3417 *
3418 * There is never an attempt to get a consistent view of multiple pages using
3419 * multiple concurrent buffer locks; in general, we only acquire a single pin
3420 * and buffer lock at a time, which is often all that the nbtree code requires.
3421 * (Actually, bt_recheck_sibling_links couples buffer locks, which is the only
3422 * exception to this general rule.)
3423 *
3424 * Operating on a copy of the page is useful because it prevents control
3425 * getting stuck in an uninterruptible state when an underlying operator class
3426 * misbehaves.
3427 */
3428 static Page
3430 {
3431 Buffer buffer;
3432 Page page;
3433 BTPageOpaque opaque;
3434 OffsetNumber maxoffset;
3438 /*
3439 * We copy the page into local storage to avoid holding pin on the buffer
3440 * longer than we must.
3441 */
3446 /*
3447 * Perform the same basic sanity checking that nbtree itself performs for
3448 * every page:
3449 */
3452 /* Only use copy of page in palloc()'d memory */
3464 /* Check page from block that ought to be meta page */
3466 {
3484 BTREE_MIN_VERSION)));
3486 /* Finished with metapage checks */
3488 }
3490 /*
3491 * Deleted pages that still use the old 32-bit XID representation have no
3492 * sane "level" field because they type pun the field, but all other pages
3493 * (including pages deleted on Postgres 14+) have a valid value.
3494 */
3496 {
3497 /* Okay, no reason not to trust btpo_level field from page */
3510 blocknum,
3512 }
3514 /*
3515 * Sanity checks for number of items on page.
3516 *
3517 * As noted at the beginning of _bt_binsrch(), an internal page must have
3518 * children, since there must always be a negative infinity downlink
3519 * (there may also be a highkey). In the case of non-rightmost leaf
3520 * pages, there must be at least a highkey. The exceptions are deleted
3521 * pages, which contain no items.
3522 *
3523 * This is correct when pages are half-dead, since internal pages are
3524 * never half-dead, and leaf pages must have a high key when half-dead
3525 * (the rightmost page can never be deleted). It's also correct with
3526 * fully deleted pages: _bt_unlink_halfdead_page() doesn't change anything
3527 * about the target page other than setting the page as fully dead, and
3528 * setting its xact field. In particular, it doesn't change the sibling
3529 * links in the deletion target itself, since they're required when index
3530 * scans land on the deletion target, and then need to move right (or need
3531 * to move left, in the case of backward index scans).
3532 */
3539 MaxIndexTuplesPerPage)));
3553 /*
3554 * In general, internal pages are never marked half-dead, except on
3555 * versions of Postgres prior to 9.4, where it can be valid transient
3556 * state. This state is nonetheless treated as corruption by VACUUM on
3557 * from version 9.4 on, so do the same here. See _bt_pagedel() for full
3558 * details.
3559 */
3565 errhint("This can be caused by an interrupted VACUUM in version 9.3 or older, before upgrade. Please REINDEX it.")));
3567 /*
3568 * Check that internal pages have no garbage items, and that no page has
3569 * an invalid combination of deletion-related page level flags
3570 */
3580 errmsg_internal("full transaction id page flag appears in non-deleted block %u in index \"%s\"",
3590 }
3592 /*
3593 * _bt_mkscankey() wrapper that automatically prevents insertion scankey from
3594 * being considered greater than the pivot tuple that its values originated
3595 * from (or some other identical pivot tuple) in the common case where there
3596 * are truncated/minus infinity attributes. Without this extra step, there
3597 * are forms of corruption that amcheck could theoretically fail to report.
3598 *
3599 * For example, invariant_g_offset() might miss a cross-page invariant failure
3600 * on an internal level if the scankey built from the first item on the
3601 * target's right sibling page happened to be equal to (not greater than) the
3602 * last item on target page. The !backward tiebreaker in _bt_compare() might
3603 * otherwise cause amcheck to assume (rather than actually verify) that the
3604 * scankey is greater.
3605 */
3608 {
3609 BTScanInsert skey;
3615 }
3617 /*
3618 * PageGetItemId() wrapper that validates returned line pointer.
3619 *
3620 * Buffer page/page item access macros generally trust that line pointers are
3621 * not corrupt, which might cause problems for verification itself. For
3622 * example, there is no bounds checking in PageGetItem(). Passing it a
3623 * corrupt line pointer can cause it to return a tuple/pointer that is unsafe
3624 * to dereference.
3625 *
3626 * Validating line pointers before tuples avoids undefined behavior and
3627 * assertion failures with corrupt indexes, making the verification process
3628 * more robust and predictable.
3629 */
3630 static ItemId
3632 OffsetNumber offset)
3633 {
3647 /*
3648 * Verify that line pointer isn't LP_REDIRECT or LP_UNUSED, since nbtree
3649 * never uses either. Verify that line pointer has storage, too, since
3650 * even LP_DEAD items should within nbtree.
3651 */
3664 }
3666 /*
3667 * BTreeTupleGetHeapTID() wrapper that enforces that a heap TID is present in
3668 * cases where that is mandatory (i.e. for non-pivot tuples)
3669 */
3673 {
3674 ItemPointer htid;
3676 /*
3677 * Caller determines whether this is supposed to be a pivot or non-pivot
3678 * tuple using page type and item offset number. Verify that tuple
3679 * metadata agrees with this.
3680 */
3685 errmsg_internal("block %u or its right sibling block or child block in index \"%s\" has unexpected pivot tuple",
3692 errmsg_internal("block %u or its right sibling block or child block in index \"%s\" has unexpected non-pivot tuple",
3700 errmsg("block %u or its right sibling block or child block in index \"%s\" contains non-pivot tuple that lacks a heap TID",
3705 }
3707 /*
3708 * Return the "pointed to" TID for itup, which is used to generate a
3709 * descriptive error message. itup must be a "data item" tuple (it wouldn't
3710 * make much sense to call here with a high key tuple, since there won't be a
3711 * valid downlink/block number to display).
3712 *
3713 * Returns either a heap TID (which will be the first heap TID in posting list
3714 * if itup is posting list tuple), or a TID that contains downlink block
3715 * number, plus some encoded metadata (e.g., the number of attributes present
3716 * in itup).
3717 */
3720 {
3721 /*
3722 * Rely on the assumption that !heapkeyspace internal page data items will
3723 * correctly return TID with downlink here -- BTreeTupleGetHeapTID() won't
3724 * recognize it as a pivot tuple, but everything still works out because
3725 * the t_tid field is still returned
3726 */
3730 /* Pivot tuple returns TID with downlink block (heapkeyspace variant) */
3732 }