@@ -407,7 +407,7 @@ verify_heapam(PG_FUNCTION_ARGS)
407407OffsetNumber successor [MaxOffsetNumber ];
408408bool lp_valid [MaxOffsetNumber ];
409409bool xmin_commit_status_ok [MaxOffsetNumber ];
410- XidCommitStatus xmin_commit_status [MaxOffsetNumber ];
410+ XidCommitStatus xmin_commit_status [MaxOffsetNumber ];
411411
412412CHECK_FOR_INTERRUPTS ();
413413
@@ -444,7 +444,7 @@ verify_heapam(PG_FUNCTION_ARGS)
444444for (ctx .offnum = FirstOffsetNumber ;ctx .offnum <=maxoff ;
445445ctx .offnum = OffsetNumberNext (ctx .offnum ))
446446{
447- BlockNumber nextblkno ;
447+ BlockNumber nextblkno ;
448448OffsetNumber nextoffnum ;
449449
450450successor [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 */
491491rditem = PageGetItemId (ctx .page ,rdoffnum );
492492if (!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 */
616616Assert (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 */
673673predecessor [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 */
727727if (xmin_commit_status_ok [ctx .offnum ]&&
728728xmin_commit_status [ctx .offnum ]== XID_ABORTED &&
@@ -1025,7 +1025,7 @@ check_tuple_visibility(HeapCheckContext *ctx, bool *xmin_commit_status_ok,
10251025HeapTupleHeader tuphdr = ctx -> tuphdr ;
10261026
10271027ctx -> 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 */
10311031xmin = HeapTupleHeaderGetXmin (tuphdr );
@@ -1837,7 +1837,7 @@ check_tuple(HeapCheckContext *ctx, bool *xmin_commit_status_ok,
18371837 * therefore cannot check it.
18381838 */
18391839if (!check_tuple_visibility (ctx ,xmin_commit_status_ok ,
1840- xmin_commit_status ))
1840+ xmin_commit_status ))
18411841return ;
18421842
18431843/*
@@ -1897,8 +1897,8 @@ FullTransactionIdFromXidAndCtx(TransactionId xid, const HeapCheckContext *ctx)
18971897diff = (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