pgindent run on access/transam/multixact.c

alvherre · alvherre · commit b37f74868d2d · 2015-06-04T15:20:28.000-03:00
This file has been patched over and over, and the differences to master
caused by pgindent are annoying enough that it seems saner to make the
older branches look the same.

Backpatch to 9.3, which is as far back as backpatching of bugfixes is
necessary.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
@@ -970,7 +970,7 @@ GetNewMultiXactId(int nmembers, MultiXactOffset *offset)
 	 */
 	if (!MultiXactIdPrecedes(result, MultiXactState->multiVacLimit) ||
 		(MultiXactState->nextOffset - MultiXactState->oldestOffset
-			> MULTIXACT_MEMBER_SAFE_THRESHOLD))
+		 > MULTIXACT_MEMBER_SAFE_THRESHOLD))
 	{
 		/*
 		 * For safety's sake, we release MultiXactGenLock while sending
@@ -1194,14 +1194,14 @@ GetMultiXactIdMembers(MultiXactId multi, MultiXactMember **members,
 	 *
 	 * An ID older than MultiXactState->oldestMultiXactId cannot possibly be
 	 * useful; it has already been removed, or will be removed shortly, by
-	 * truncation.  Returning the wrong values could lead
-	 * to an incorrect visibility result.  However, to support pg_upgrade we
-	 * need to allow an empty set to be returned regardless, if the caller is
-	 * willing to accept it; the caller is expected to check that it's an
-	 * allowed condition (such as ensuring that the infomask bits set on the
-	 * tuple are consistent with the pg_upgrade scenario).  If the caller is
-	 * expecting this to be called only on recently created multis, then we
-	 * raise an error.
+	 * truncation.  Returning the wrong values could lead to an incorrect
+	 * visibility result.  However, to support pg_upgrade we need to allow an
+	 * empty set to be returned regardless, if the caller is willing to accept
+	 * it; the caller is expected to check that it's an allowed condition
+	 * (such as ensuring that the infomask bits set on the tuple are
+	 * consistent with the pg_upgrade scenario).  If the caller is expecting
+	 * this to be called only on recently created multis, then we raise an
+	 * error.
 	 *
 	 * Conversely, an ID >= nextMXact shouldn't ever be seen here; if it is
 	 * seen, it implies undetected ID wraparound has occurred.  This raises a
@@ -2142,11 +2142,11 @@ MultiXactSetNextMXact(MultiXactId nextMulti,
 	 * enough to contain the next value that would be created.
 	 *
 	 * We need to do this pretty early during the first startup in binary
-	 * upgrade mode: before StartupMultiXact() in fact, because this routine is
-	 * called even before that by StartupXLOG().  And we can't do it earlier
-	 * than at this point, because during that first call of this routine we
-	 * determine the MultiXactState->nextMXact value that MaybeExtendOffsetSlru
-	 * needs.
+	 * upgrade mode: before StartupMultiXact() in fact, because this routine
+	 * is called even before that by StartupXLOG().  And we can't do it
+	 * earlier than at this point, because during that first call of this
+	 * routine we determine the MultiXactState->nextMXact value that
+	 * MaybeExtendOffsetSlru needs.
 	 */
 	if (IsBinaryUpgrade)
 		MaybeExtendOffsetSlru();
@@ -2221,11 +2221,11 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
 
 	/*
 	 * Determine the offset of the oldest multixact that might still be
-	 * referenced.  Normally, we can read the offset from the multixact itself,
-	 * but there's an important special case: if there are no multixacts in
-	 * existence at all, oldest_datminmxid obviously can't point to one.  It
-	 * will instead point to the multixact ID that will be assigned the next
-	 * time one is needed.
+	 * referenced.  Normally, we can read the offset from the multixact
+	 * itself, but there's an important special case: if there are no
+	 * multixacts in existence at all, oldest_datminmxid obviously can't point
+	 * to one.  It will instead point to the multixact ID that will be
+	 * assigned the next time one is needed.
 	 *
 	 * NB: oldest_dataminmxid is the oldest multixact that might still be
 	 * referenced from a table, unlike in DetermineSafeOldestOffset, where we
@@ -2539,10 +2539,9 @@ DetermineSafeOldestOffset(MultiXactId oldestMXact)
 	 * obviously can't point to one.  It will instead point to the multixact
 	 * ID that will be assigned the next time one is needed.
 	 *
-	 * NB: oldestMXact should be the oldest multixact that still exists in
-	 * the SLRU, unlike in SetMultiXactIdLimit, where we do this same
-	 * computation based on the oldest value that might be referenced in a
-	 * table.
+	 * NB: oldestMXact should be the oldest multixact that still exists in the
+	 * SLRU, unlike in SetMultiXactIdLimit, where we do this same computation
+	 * based on the oldest value that might be referenced in a table.
 	 */
 	LWLockAcquire(MultiXactGenLock, LW_SHARED);
 	if (MultiXactState->nextMXact == oldestMXact)
@@ -2698,9 +2697,9 @@ int
 MultiXactMemberFreezeThreshold(void)
 {
 	MultiXactOffset members;
-	uint32 multixacts;
-	uint32 victim_multixacts;
-	double fraction;
+	uint32		multixacts;
+	uint32		victim_multixacts;
+	double		fraction;
 
 	ReadMultiXactCounts(&multixacts, &members);
 
@@ -2819,7 +2818,7 @@ SlruScanDirCbFindEarliest(SlruCtl ctl, char *filename, int segpage, void *data)
 void
 TruncateMultiXact(void)
 {
-	MultiXactId		oldestMXact;
+	MultiXactId oldestMXact;
 	MultiXactOffset oldestOffset;
 	MultiXactOffset nextOffset;
 	mxtruncinfo trunc;
@@ -2879,7 +2878,6 @@ TruncateMultiXact(void)
 	SimpleLruTruncate(MultiXactOffsetCtl,
 					  MultiXactIdToOffsetPage(oldestMXact));
 
-
 	/*
 	 * Now, and only now, we can advance the stop point for multixact members.
 	 * If we did it any sooner, the segments we deleted above might already
