@@ -407,7 +407,7 @@ verify_heapam(PG_FUNCTION_ARGS)
407407 OffsetNumber successor [MaxOffsetNumber ];
408408 bool lp_valid [MaxOffsetNumber ];
409409 bool xmin_commit_status_ok [MaxOffsetNumber ];
410- XidCommitStatus xmin_commit_status [MaxOffsetNumber ];
410+ XidCommitStatus xmin_commit_status [MaxOffsetNumber ];
411411
412412 CHECK_FOR_INTERRUPTS ();
413413
@@ -444,7 +444,7 @@ verify_heapam(PG_FUNCTION_ARGS)
444444 for (ctx .offnum = FirstOffsetNumber ; ctx .offnum <= maxoff ;
445445 ctx .offnum = OffsetNumberNext (ctx .offnum ))
446446 {
447- BlockNumber nextblkno ;
447+ BlockNumber nextblkno ;
448448 OffsetNumber nextoffnum ;
449449
450450 successor [ctx .offnum ] = InvalidOffsetNumber ;
@@ -484,9 +484,9 @@ verify_heapam(PG_FUNCTION_ARGS)
484484
485485 /*
486486 * Since we've checked that this redirect points to a line
487- * pointer between FirstOffsetNumber and maxoff, it should
488- * now be safe to fetch the referenced line pointer. We expect
489- * it to be LP_NORMAL; if not, that's corruption.
487+ * pointer between FirstOffsetNumber and maxoff, it should now
488+ * be safe to fetch the referenced line pointer. We expect it
489+ * to be LP_NORMAL; if not, that's corruption.
490490 */
491491 rditem = PageGetItemId (ctx .page , rdoffnum );
492492 if (!ItemIdIsUsed (rditem ))
@@ -610,8 +610,8 @@ verify_heapam(PG_FUNCTION_ARGS)
610610 {
611611 /*
612612 * We should not have set successor[ctx.offnum] to a value
613- * other than InvalidOffsetNumber unless that line pointer
614- * is LP_NORMAL.
613+ * other than InvalidOffsetNumber unless that line pointer is
614+ * LP_NORMAL.
615615 */
616616 Assert (ItemIdIsNormal (next_lp ));
617617
@@ -642,8 +642,8 @@ verify_heapam(PG_FUNCTION_ARGS)
642642 }
643643
644644 /*
645- * If the next line pointer is a redirect, or if it's a tuple
646- * but the XMAX of this tuple doesn't match the XMIN of the next
645+ * If the next line pointer is a redirect, or if it's a tuple but
646+ * the XMAX of this tuple doesn't match the XMIN of the next
647647 * tuple, then the two aren't part of the same update chain and
648648 * there is nothing more to do.
649649 */
@@ -667,8 +667,8 @@ verify_heapam(PG_FUNCTION_ARGS)
667667 }
668668
669669 /*
670- * This tuple and the tuple to which it points seem to be part
671- * of an update chain.
670+ * This tuple and the tuple to which it points seem to be part of
671+ * an update chain.
672672 */
673673 predecessor [nextoffnum ] = ctx .offnum ;
674674
@@ -721,8 +721,8 @@ verify_heapam(PG_FUNCTION_ARGS)
721721 }
722722
723723 /*
724- * If the current tuple's xmin is aborted but the successor tuple's
725- * xmin is in-progress or committed, that's corruption.
724+ * If the current tuple's xmin is aborted but the successor
725+ * tuple's xmin is in-progress or committed, that's corruption.
726726 */
727727 if (xmin_commit_status_ok [ctx .offnum ] &&
728728 xmin_commit_status [ctx .offnum ] == XID_ABORTED &&
@@ -1025,7 +1025,7 @@ check_tuple_visibility(HeapCheckContext *ctx, bool *xmin_commit_status_ok,
10251025 HeapTupleHeader tuphdr = ctx -> tuphdr ;
10261026
10271027 ctx -> tuple_could_be_pruned = true; /* have not yet proven otherwise */
1028- * xmin_commit_status_ok = false; /* have not yet proven otherwise */
1028+ * xmin_commit_status_ok = false; /* have not yet proven otherwise */
10291029
10301030 /* If xmin is normal, it should be within valid range */
10311031 xmin = HeapTupleHeaderGetXmin (tuphdr );
@@ -1837,7 +1837,7 @@ check_tuple(HeapCheckContext *ctx, bool *xmin_commit_status_ok,
18371837 * therefore cannot check it.
18381838 */
18391839 if (!check_tuple_visibility (ctx , xmin_commit_status_ok ,
1840- xmin_commit_status ))
1840+ xmin_commit_status ))
18411841 return ;
18421842
18431843 /*
@@ -1897,8 +1897,8 @@ FullTransactionIdFromXidAndCtx(TransactionId xid, const HeapCheckContext *ctx)
18971897 diff = (int32 ) (ctx -> next_xid - xid );
18981898
18991899 /*
1900- * In cases of corruption we might see a 32bit xid that is before epoch
1901- * 0. We can't represent that as a 64bit xid, due to 64bit xids being
1900+ * In cases of corruption we might see a 32bit xid that is before epoch 0.
1901+ * We can't represent that as a 64bit xid, due to 64bit xids being
19021902 * unsigned integers, without the modulo arithmetic of 32bit xid. There's
19031903 * no really nice way to deal with that, but it works ok enough to use
19041904 * FirstNormalFullTransactionId in that case, as a freshly initdb'd
0 commit comments