Pre-beta mechanical code beautification.

Run pgindent, pgperltidy, and reformat-dat-files.

This set of diffs is a bit larger than typical.  We've updated to
pg_bsd_indent 2.1.2, which properly indents variable declarations that
have multi-line initialization expressions (the continuation lines are
now indented one tab stop).  We've also updated to perltidy version
20230309 and changed some of its settings, which reduces its desire to
add whitespace to lines to make assignments etc. line up.  Going
forward, that should make for fewer random-seeming changes to existing
code.

Discussion: https://postgr.es/m/[email protected]

6 files changed, 15 insertions, 14 deletions

diff --git a/src/backend/access/heap/heapam.c b/src/backend/access/heap/heapam.c
index 0124f37911f..7ed72abe597 100644
--- a/src/backend/access/heap/heapam.c
+++ b/src/backend/access/heap/heapam.c
@@ -2491,7 +2491,7 @@ static inline bool
 xmax_infomask_changed(uint16 new_infomask, uint16 old_infomask)
 {
 	const uint16 interesting =
-	HEAP_XMAX_IS_MULTI | HEAP_XMAX_LOCK_ONLY | HEAP_LOCK_MASK;
+		HEAP_XMAX_IS_MULTI | HEAP_XMAX_LOCK_ONLY | HEAP_LOCK_MASK;
 
 	if ((new_infomask & interesting) != (old_infomask & interesting))
 		return true;
diff --git a/src/backend/access/heap/heapam_handler.c b/src/backend/access/heap/heapam_handler.c
index cbb35aa73d6..646135cc21c 100644
--- a/src/backend/access/heap/heapam_handler.c
+++ b/src/backend/access/heap/heapam_handler.c
@@ -334,8 +334,8 @@ heapam_tuple_update(Relation relation, ItemPointer otid, TupleTableSlot *slot,
 	 * Note: heap_update returns the tid (location) of the new tuple in the
 	 * t_self field.
 	 *
-	 * If the update is not HOT, we must update all indexes. If the update
-	 * is HOT, it could be that we updated summarized columns, so we either
+	 * If the update is not HOT, we must update all indexes. If the update is
+	 * HOT, it could be that we updated summarized columns, so we either
 	 * update only summarized indexes, or none at all.
 	 */
 	if (result != TM_Ok)
diff --git a/src/backend/access/heap/hio.c b/src/backend/access/heap/hio.c
index fb95c19e90f..c275b08494d 100644
--- a/src/backend/access/heap/hio.c
+++ b/src/backend/access/heap/hio.c
@@ -376,7 +376,7 @@ RelationAddBlocks(Relation relation, BulkInsertState bistate,
 		if (use_fsm && i >= not_in_fsm_pages)
 		{
 			Size		freespace = BufferGetPageSize(victim_buffers[i]) -
-			SizeOfPageHeaderData;
+				SizeOfPageHeaderData;
 
 			RecordPageWithFreeSpace(relation, curBlock, freespace);
 		}
diff --git a/src/backend/access/heap/pruneheap.c b/src/backend/access/heap/pruneheap.c
index 20df39c1497..47b9e209154 100644
--- a/src/backend/access/heap/pruneheap.c
+++ b/src/backend/access/heap/pruneheap.c
@@ -532,7 +532,7 @@ heap_prune_satisfies_vacuum(PruneState *prstate, HeapTuple tup, Buffer buffer)
 		if (!TransactionIdIsValid(prstate->old_snap_xmin))
 		{
 			TransactionId horizon =
-			GlobalVisTestNonRemovableHorizon(prstate->vistest);
+				GlobalVisTestNonRemovableHorizon(prstate->vistest);
 
 			TransactionIdLimitedForOldSnapshots(horizon, prstate->rel,
 												&prstate->old_snap_xmin,
diff --git a/src/backend/access/heap/vacuumlazy.c b/src/backend/access/heap/vacuumlazy.c
index cda8889f5ea..4eb953f9047 100644
--- a/src/backend/access/heap/vacuumlazy.c
+++ b/src/backend/access/heap/vacuumlazy.c
@@ -389,6 +389,7 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
 	Assert(params->index_cleanup != VACOPTVALUE_UNSPECIFIED);
 	Assert(params->truncate != VACOPTVALUE_UNSPECIFIED &&
 		   params->truncate != VACOPTVALUE_AUTO);
+
 	/*
 	 * While VacuumFailSafeActive is reset to false before calling this, we
 	 * still need to reset it here due to recursive calls.
@@ -1813,12 +1814,12 @@ retry:
 		{
 			/*
 			 * We have no freeze plans to execute, so there's no added cost
-			 * from following the freeze path.  That's why it was chosen.
-			 * This is important in the case where the page only contains
-			 * totally frozen tuples at this point (perhaps only following
-			 * pruning).  Such pages can be marked all-frozen in the VM by our
-			 * caller, even though none of its tuples were newly frozen here
-			 * (note that the "no freeze" path never sets pages all-frozen).
+			 * from following the freeze path.  That's why it was chosen. This
+			 * is important in the case where the page only contains totally
+			 * frozen tuples at this point (perhaps only following pruning).
+			 * Such pages can be marked all-frozen in the VM by our caller,
+			 * even though none of its tuples were newly frozen here (note
+			 * that the "no freeze" path never sets pages all-frozen).
 			 *
 			 * We never increment the frozen_pages instrumentation counter
 			 * here, since it only counts pages with newly frozen tuples
@@ -3117,8 +3118,8 @@ dead_items_max_items(LVRelState *vacrel)
 {
 	int64		max_items;
 	int			vac_work_mem = IsAutoVacuumWorkerProcess() &&
-	autovacuum_work_mem != -1 ?
-	autovacuum_work_mem : maintenance_work_mem;
+		autovacuum_work_mem != -1 ?
+		autovacuum_work_mem : maintenance_work_mem;
 
 	if (vacrel->nindexes > 0)
 	{
diff --git a/src/backend/access/heap/visibilitymap.c b/src/backend/access/heap/visibilitymap.c
index ac91d1a14da..7d54ec9c0f7 100644
--- a/src/backend/access/heap/visibilitymap.c
+++ b/src/backend/access/heap/visibilitymap.c
@@ -626,7 +626,7 @@ vm_readbuf(Relation rel, BlockNumber blkno, bool extend)
 static Buffer
 vm_extend(Relation rel, BlockNumber vm_nblocks)
 {
-	Buffer buf;
+	Buffer		buf;
 
 	buf = ExtendBufferedRelTo(EB_REL(rel), VISIBILITYMAP_FORKNUM, NULL,
 							  EB_CREATE_FORK_IF_NEEDED |