@@ -227,12 +227,12 @@ bt_index_check_internal(Oid indrelid, bool parentcheck, bool heapallindexed)
227227 * with heap relation locked first to prevent deadlocking). In hot
228228 * standby mode this will raise an error when parentcheck is true.
229229 *
230- * There is no need for the usual indcheckxmin usability horizon test here,
231- * even in the heapallindexed case, because index undergoing verification
232- * only needs to have entries for a new transaction snapshot. (If this is
233- * a parentcheck verification, there is no question about committed or
234- * recently dead heap tuples lacking index entries due to concurrent
235- * activity.)
230+ * There is no need for the usual indcheckxmin usability horizon test
231+ *here, even in the heapallindexed case, because index undergoing
232+ *verification only needs to have entries for a new transaction snapshot.
233+ *(If this is a parentcheck verification, there is no question about
234+ *committed or recently dead heap tuples lacking index entries due to
235+ *concurrent activity.)
236236 */
237237indrel = index_open (indrelid ,lockmode );
238238
@@ -366,8 +366,8 @@ bt_check_every_level(Relation rel, Relation heaprel, bool readonly,
366366 * index fingerprinting should have reached all tuples returned by
367367 * IndexBuildHeapScan().
368368 *
369- * In readonly case, we also check for problems with missing downlinks.
370- * A second Bloom filter is used for this.
369+ * In readonly case, we also check for problems with missing
370+ *downlinks. A second Bloom filter is used for this.
371371 */
372372if (!state -> readonly )
373373{
@@ -378,13 +378,13 @@ bt_check_every_level(Relation rel, Relation heaprel, bool readonly,
378378 * READ COMMITTED mode. A new snapshot is guaranteed to have all
379379 * the entries it requires in the index.
380380 *
381- * We must defend against the possibility that an old xact snapshot
382- * was returned at higher isolation levels when that snapshot is
383- * not safe for index scans of the target index. This is possible
384- * when the snapshot sees tuples that are before the index's
385- * indcheckxmin horizon. Throwing an error here should be very
386- * rare. It doesn't seem worth using a secondary snapshot to avoid
387- * this.
381+ * We must defend against the possibility that an old xact
382+ *snapshot was returned at higher isolation levels when that
383+ *snapshot is not safe for index scans of the target index. This
384+ *is possible when the snapshot sees tuples that are before the
385+ *index's indcheckxmin horizon. Throwing an error here should be
386+ *very rare. It doesn't seem worth using a secondary snapshot to
387+ *avoid this.
388388 */
389389if (IsolationUsesXactSnapshot ()&& rel -> rd_index -> indcheckxmin &&
390390!TransactionIdPrecedes (HeapTupleHeaderGetXmin (rel -> rd_indextuple -> t_data ),
@@ -396,13 +396,13 @@ bt_check_every_level(Relation rel, Relation heaprel, bool readonly,
396396}
397397else
398398{
399- int64 total_pages ;
399+ int64 total_pages ;
400400
401401/*
402402 * Extra readonly downlink check.
403403 *
404- * In readonly case, we know that there cannot be a concurrent page
405- * split or a concurrent page deletion, which gives us the
404+ * In readonly case, we know that there cannot be a concurrent
405+ *page split or a concurrent page deletion, which gives us the
406406 * opportunity to verify that every non-ignorable page had a
407407 * downlink one level up. We must be tolerant of interrupted page
408408 * splits and page deletions, though. This is taken care of in
@@ -491,9 +491,9 @@ bt_check_every_level(Relation rel, Relation heaprel, bool readonly,
491491}
492492
493493/*
494- * Create our own scan for IndexBuildHeapScan(), rather than getting it
495- * to do so for us. This is required so that we can actually use the
496- * MVCC snapshot registered earlier in !readonly case.
494+ * Create our own scan for IndexBuildHeapScan(), rather than getting
495+ *it to do so for us. This is required so that we can actually use
496+ *the MVCC snapshot registered earlier in !readonly case.
497497 *
498498 * Note that IndexBuildHeapScan() calls heap_endscan() for us.
499499 */
@@ -607,10 +607,10 @@ bt_check_level_from_leftmost(BtreeCheckState *state, BtreeLevel level)
607607{
608608/*
609609 * Since there cannot be a concurrent VACUUM operation in readonly
610- * mode, and since a page has no links within other pages (siblings
611- * and parent) once it is marked fully deleted, it should be
612- * impossible to land on a fully deleted page in readonly mode.
613- * See bt_downlink_check() for further details.
610+ * mode, and since a page has no links within other pages
611+ *(siblings and parent) once it is marked fully deleted, it
612+ *should be impossible to land on a fully deleted page in
613+ *readonly mode. See bt_downlink_check() for further details.
614614 *
615615 * The bt_downlink_check() P_ISDELETED() check is repeated here so
616616 * that pages that are only reachable through sibling links get
@@ -799,8 +799,8 @@ bt_target_page_check(BtreeCheckState *state)
799799P_ISLEAF (topaque ) ?"leaf" :"internal" ,state -> targetblock );
800800
801801/*
802- * Check the number of attributes in high key. Note, rightmost page doesn't
803- * contain a high key, so nothing to check
802+ * Check the number of attributes in high key. Note, rightmost page
803+ *doesn't contain a high key, so nothing to check
804804 */
805805if (!P_RIGHTMOST (topaque )&&
806806!_bt_check_natts (state -> rel ,state -> target ,P_HIKEY ))
@@ -845,8 +845,8 @@ bt_target_page_check(BtreeCheckState *state)
845845
846846/*
847847 * lp_len should match the IndexTuple reported length exactly, since
848- * lp_len is completely redundant in indexes, and both sources of tuple
849- * length are MAXALIGN()'d. nbtree does not use lp_len all that
848+ * lp_len is completely redundant in indexes, and both sources of
849+ *tuple length are MAXALIGN()'d. nbtree does not use lp_len all that
850850 * frequently, and is surprisingly tolerant of corrupt lp_len fields.
851851 */
852852if (tupsize != ItemIdGetLength (itemid ))
@@ -1441,13 +1441,13 @@ bt_downlink_check(BtreeCheckState *state, BlockNumber childblock,
14411441static void
14421442bt_downlink_missing_check (BtreeCheckState * state )
14431443{
1444- BTPageOpaque topaque = (BTPageOpaque )PageGetSpecialPointer (state -> target );
1445- ItemId itemid ;
1446- IndexTuple itup ;
1447- Page child ;
1448- BTPageOpaque copaque ;
1449- uint32 level ;
1450- BlockNumber childblk ;
1444+ BTPageOpaque topaque = (BTPageOpaque )PageGetSpecialPointer (state -> target );
1445+ ItemId itemid ;
1446+ IndexTuple itup ;
1447+ Page child ;
1448+ BTPageOpaque copaque ;
1449+ uint32 level ;
1450+ BlockNumber childblk ;
14511451
14521452Assert (state -> heapallindexed && state -> readonly );
14531453Assert (!P_IGNORE (topaque ));
@@ -1462,14 +1462,15 @@ bt_downlink_missing_check(BtreeCheckState *state)
14621462 * page split in passing, when it notices that the left sibling page is
14631463 * P_INCOMPLETE_SPLIT().
14641464 *
1465- * In general, VACUUM is not prepared for there to be no downlink to a page
1466- * that it deletes. This is the main reason why the lack of a downlink can
1467- * be reported as corruption here. It's not obvious that an invalid
1468- * missing downlink can result in wrong answers to queries, though, since
1469- * index scans that land on the child may end up consistently moving right.
1470- * The handling of concurrent page splits (and page deletions) within
1471- * _bt_moveright() cannot distinguish inconsistencies that last for a
1472- * moment from inconsistencies that are permanent and irrecoverable.
1465+ * In general, VACUUM is not prepared for there to be no downlink to a
1466+ * page that it deletes. This is the main reason why the lack of a
1467+ * downlink can be reported as corruption here. It's not obvious that an
1468+ * invalid missing downlink can result in wrong answers to queries,
1469+ * though, since index scans that land on the child may end up
1470+ * consistently moving right. The handling of concurrent page splits (and
1471+ * page deletions) within _bt_moveright() cannot distinguish
1472+ * inconsistencies that last for a moment from inconsistencies that are
1473+ * permanent and irrecoverable.
14731474 *
14741475 * VACUUM isn't even prepared to delete pages that have no downlink due to
14751476 * an incomplete page split, but it can detect and reason about that case
@@ -1498,8 +1499,8 @@ bt_downlink_missing_check(BtreeCheckState *state)
14981499
14991500/*
15001501 * Target is probably the "top parent" of a multi-level page deletion.
1501- * We'll need to descend the subtree to make sure that descendant pages are
1502- * consistent with that, though.
1502+ * We'll need to descend the subtree to make sure that descendant pages
1503+ *are consistent with that, though.
15031504 *
15041505 * If the target page (which must be non-ignorable) is a leaf page, then
15051506 * clearly it can't be the top parent. The lack of a downlink is probably
@@ -1562,14 +1563,14 @@ bt_downlink_missing_check(BtreeCheckState *state)
15621563 * bt_downlink_check() does not visit pages reachable through negative
15631564 * infinity items. Besides, bt_downlink_check() is unwilling to descend
15641565 * multiple levels. (The similar bt_downlink_check() P_ISDELETED() check
1565- * within bt_check_level_from_leftmost() won't reach the page either, since
1566- * the leaf's live siblings should have their sibling links updated to
1567- * bypass the deletion target page when it is marked fully dead.)
1566+ * within bt_check_level_from_leftmost() won't reach the page either,
1567+ *since the leaf's live siblings should have their sibling links updated
1568+ *to bypass the deletion target page when it is marked fully dead.)
15681569 *
15691570 * If this error is raised, it might be due to a previous multi-level page
1570- * deletion that failed to realize that it wasn't yet safe to mark the leaf
1571- * page as fully dead. A "dangling downlink" will still remain when this
1572- * happens. The fact that the dangling downlink's page (the leaf's
1571+ * deletion that failed to realize that it wasn't yet safe to mark the
1572+ *leaf page as fully dead. A "dangling downlink" will still remain when
1573+ *this happens. The fact that the dangling downlink's page (the leaf's
15731574 * parent/ancestor page) lacked a downlink is incidental.
15741575 */
15751576if (P_ISDELETED (copaque ))
@@ -1583,14 +1584,14 @@ bt_downlink_missing_check(BtreeCheckState *state)
15831584(uint32 )state -> targetlsn )));
15841585
15851586/*
1586- * Iff leaf page is half-dead, its high key top parent link should point to
1587- * what VACUUM considered to be the top parent page at the instant it was
1588- * interrupted. Provided the high key link actually points to the target
1589- * page, the missing downlink we detected is consistent with there having
1590- * been an interrupted multi-level page deletion. This means that the
1591- * subtree with the target page at its root (a page deletion chain) is in a
1592- * consistent state, enabling VACUUM to resume deleting the entire chain
1593- * the next time it encounters the half-dead leaf page.
1587+ * Iff leaf page is half-dead, its high key top parent link should point
1588+ *to what VACUUM considered to be the top parent page at the instant it
1589+ *was interrupted. Provided the high key link actually points to the
1590+ *target page, the missing downlink we detected is consistent with there
1591+ *having been an interrupted multi-level page deletion. This means that
1592+ *the subtree with the target page at its root (a page deletion chain) is
1593+ *in a consistent state, enabling VACUUM to resume deleting the entire
1594+ *chain the next time it encounters the half-dead leaf page.
15941595 */
15951596if (P_ISHALFDEAD (copaque )&& !P_RIGHTMOST (copaque ))
15961597{
@@ -1681,16 +1682,17 @@ bt_tuple_present_callback(Relation index, HeapTuple htup, Datum *values,
16811682 * are assumed immutable. While the LP_DEAD bit is mutable in leaf pages,
16821683 * that's ItemId metadata, which was not fingerprinted. (There will often
16831684 * be some dead-to-everyone IndexTuples fingerprinted by the Bloom filter,
1684- * but we only try to detect the absence of needed tuples, so that's okay.)
1685+ * but we only try to detect the absence of needed tuples, so that's
1686+ * okay.)
16851687 *
1686- * Note that we rely on deterministic index_form_tuple() TOAST compression.
1687- * If index_form_tuple() was ever enhanced to compress datums out-of-line,
1688- * or otherwise varied when or how compression was applied, our assumption
1689- * would break, leading to false positive reports of corruption. It's also
1690- * possible that non-pivot tuples could in the future have alternative
1691- * equivalent representations (e.g. by using the INDEX_ALT_TID_MASK bit).
1692- * For now, we don't decompress/normalize toasted values as part of
1693- * fingerprinting.
1688+ * Note that we rely on deterministic index_form_tuple() TOAST
1689+ *compression. If index_form_tuple() was ever enhanced to compress datums
1690+ *out-of-line, or otherwise varied when or how compression was applied,
1691+ *our assumption would break, leading to false positive reports of
1692+ *corruption. It's also possible that non-pivot tuples could in the
1693+ *future have alternative equivalent representations (e.g. by using the
1694+ *INDEX_ALT_TID_MASK bit). For now, we don't decompress/normalize toasted
1695+ *values as part of fingerprinting.
16941696 */
16951697itup = index_form_tuple (RelationGetDescr (index ),values ,isnull );
16961698itup -> t_tid = htup -> t_self ;
@@ -1905,19 +1907,19 @@ palloc_btree_page(BtreeCheckState *state, BlockNumber blocknum)
19051907 * Sanity checks for number of items on page.
19061908 *
19071909 * As noted at the beginning of _bt_binsrch(), an internal page must have
1908- * children, since there must always be a negative infinity downlink (there
1909- * may also be a highkey). In the case of non-rightmost leaf pages, there
1910- * must be at least a highkey.
1910+ * children, since there must always be a negative infinity downlink
1911+ *(there may also be a highkey). In the case of non-rightmost leaf
1912+ *pages, there must be at least a highkey.
19111913 *
1912- * This is correct when pages are half-dead, since internal pages are never
1913- * half-dead, and leaf pages must have a high key when half-dead (the
1914- * rightmost page can never be deleted). It's also correct with fully
1915- * deleted pages: _bt_unlink_halfdead_page() doesn't change anything about
1916- * the target page other than setting the page as fully dead, and setting
1917- * its xact field. In particular, it doesn't change the sibling links in
1918- * the deletion target itself, since they're required when index scans land
1919- * on the deletion target, and then need to move right (or need to move
1920- * left, in the case of backward index scans).
1914+ * This is correct when pages are half-dead, since internal pages are
1915+ *never half-dead, and leaf pages must have a high key when half-dead
1916+ *(the rightmost page can never be deleted). It's also correct with
1917+ *fully deleted pages: _bt_unlink_halfdead_page() doesn't change anything
1918+ *about the target page other than setting the page as fully dead, and
1919+ *setting its xact field. In particular, it doesn't change the sibling
1920+ *links in the deletion target itself, since they're required when index
1921+ *scans land on the deletion target, and then need to move right (or need
1922+ *to move left, in the case of backward index scans).
19211923 */
19221924maxoffset = PageGetMaxOffsetNumber (page );
19231925if (maxoffset > MaxIndexTuplesPerPage )