Re-run pgindent, fixing a problem where comment lines after a blank

comment line where output as too long, and update typedefs for /lib
directory.  Also fix case where identifiers were used as variable names
in the backend, but as typedefs in ecpg (favor the backend for
indenting).

Backpatch to 8.1.X.

8 files changed, 163 insertions, 161 deletions

diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index af254da173d..f55f2c2c2fa 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -42,7 +42,7 @@
  * Portions Copyright (c) 1996-2005, PostgreSQL Global Development Group
  * Portions Copyright (c) 1994, Regents of the University of California
  *
- * $PostgreSQL: pgsql/src/backend/access/transam/multixact.c,v 1.11 2005/10/28 19:00:19 tgl Exp $
+ * $PostgreSQL: pgsql/src/backend/access/transam/multixact.c,v 1.11.2.1 2005/11/22 18:23:05 momjian Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -129,22 +129,23 @@ typedef struct MultiXactStateData
 	 * member of a MultiXact, and that MultiXact would have to be created
 	 * during or after the lock acquisition.)
 	 *
-	 * OldestVisibleMXactId[k] is the oldest MultiXactId each backend's current
-	 * transaction(s) think is potentially live, or InvalidMultiXactId when
-	 * not in a transaction or not in a transaction that's paid any attention
-	 * to MultiXacts yet.  This is computed when first needed in a given
-	 * transaction, and cleared at transaction end.  We can compute it as the
-	 * minimum of the valid OldestMemberMXactId[] entries at the time we
-	 * compute it (using nextMXact if none are valid).	Each backend is
+	 * OldestVisibleMXactId[k] is the oldest MultiXactId each backend's
+	 * current transaction(s) think is potentially live, or InvalidMultiXactId
+	 * when not in a transaction or not in a transaction that's paid any
+	 * attention to MultiXacts yet.  This is computed when first needed in a
+	 * given transaction, and cleared at transaction end.  We can compute it
+	 * as the minimum of the valid OldestMemberMXactId[] entries at the time
+	 * we compute it (using nextMXact if none are valid).  Each backend is
 	 * required not to attempt to access any SLRU data for MultiXactIds older
 	 * than its own OldestVisibleMXactId[] setting; this is necessary because
 	 * the checkpointer could truncate away such data at any instant.
 	 *
-	 * The checkpointer can compute the safe truncation point as the oldest valid
-	 * value among all the OldestMemberMXactId[] and OldestVisibleMXactId[]
-	 * entries, or nextMXact if none are valid. Clearly, it is not possible
-	 * for any later-computed OldestVisibleMXactId value to be older than
-	 * this, and so there is no risk of truncating data that is still needed.
+	 * The checkpointer can compute the safe truncation point as the oldest
+	 * valid value among all the OldestMemberMXactId[] and
+	 * OldestVisibleMXactId[] entries, or nextMXact if none are valid.
+	 * Clearly, it is not possible for any later-computed OldestVisibleMXactId
+	 * value to be older than this, and so there is no risk of truncating data
+	 * that is still needed.
 	 */
 	MultiXactId perBackendXactIds[1];	/* VARIABLE LENGTH ARRAY */
 } MultiXactStateData;
@@ -631,8 +632,8 @@ CreateMultiXactId(int nxids, TransactionId *xids)
 	}
 
 	/*
-	 * Assign the MXID and offsets range to use, and make sure there is
-	 * space in the OFFSETs and MEMBERs files.  NB: this routine does
+	 * Assign the MXID and offsets range to use, and make sure there is space
+	 * in the OFFSETs and MEMBERs files.  NB: this routine does
 	 * START_CRIT_SECTION().
 	 */
 	multi = GetNewMultiXactId(nxids, &offset);
@@ -788,9 +789,9 @@ GetNewMultiXactId(int nxids, MultiXactOffset *offset)
 	ExtendMultiXactOffset(result);
 
 	/*
-	 * Reserve the members space, similarly to above.  Also, be
-	 * careful not to return zero as the starting offset for any multixact.
-	 * See GetMultiXactIdMembers() for motivation.
+	 * Reserve the members space, similarly to above.  Also, be careful not to
+	 * return zero as the starting offset for any multixact. See
+	 * GetMultiXactIdMembers() for motivation.
 	 */
 	nextOffset = MultiXactState->nextOffset;
 	if (nextOffset == 0)
@@ -804,8 +805,8 @@ GetNewMultiXactId(int nxids, MultiXactOffset *offset)
 	ExtendMultiXactMember(nextOffset, nxids);
 
 	/*
-	 * Critical section from here until caller has written the data into
-	 * the just-reserved SLRU space; we don't want to error out with a partly
+	 * Critical section from here until caller has written the data into the
+	 * just-reserved SLRU space; we don't want to error out with a partly
 	 * written MultiXact structure.  (In particular, failing to write our
 	 * start offset after advancing nextMXact would effectively corrupt the
 	 * previous MultiXact.)
@@ -819,8 +820,8 @@ GetNewMultiXactId(int nxids, MultiXactOffset *offset)
 	 * We don't care about MultiXactId wraparound here; it will be handled by
 	 * the next iteration.	But note that nextMXact may be InvalidMultiXactId
 	 * after this routine exits, so anyone else looking at the variable must
-	 * be prepared to deal with that.  Similarly, nextOffset may be zero,
-	 * but we won't use that as the actual start offset of the next multixact.
+	 * be prepared to deal with that.  Similarly, nextOffset may be zero, but
+	 * we won't use that as the actual start offset of the next multixact.
 	 */
 	(MultiXactState->nextMXact)++;
 
@@ -881,7 +882,7 @@ GetMultiXactIdMembers(MultiXactId multi, TransactionId **xids)
 	 * SLRU data if we did try to examine it.
 	 *
 	 * Conversely, an ID >= nextMXact shouldn't ever be seen here; if it is
-	 * seen, it implies undetected ID wraparound has occurred.  We just
+	 * seen, it implies undetected ID wraparound has occurred.	We just
 	 * silently assume that such an ID is no longer running.
 	 *
 	 * Shared lock is enough here since we aren't modifying any global state.
@@ -897,7 +898,7 @@ GetMultiXactIdMembers(MultiXactId multi, TransactionId **xids)
 
 	/*
 	 * Acquire the shared lock just long enough to grab the current counter
-	 * values.  We may need both nextMXact and nextOffset; see below.
+	 * values.	We may need both nextMXact and nextOffset; see below.
 	 */
 	LWLockAcquire(MultiXactGenLock, LW_SHARED);
 
@@ -915,27 +916,27 @@ GetMultiXactIdMembers(MultiXactId multi, TransactionId **xids)
 
 	/*
 	 * Find out the offset at which we need to start reading MultiXactMembers
-	 * and the number of members in the multixact.  We determine the latter
-	 * as the difference between this multixact's starting offset and the
-	 * next one's.  However, there are some corner cases to worry about:
+	 * and the number of members in the multixact.	We determine the latter as
+	 * the difference between this multixact's starting offset and the next
+	 * one's.  However, there are some corner cases to worry about:
 	 *
-	 * 1. This multixact may be the latest one created, in which case there
-	 * is no next one to look at.  In this case the nextOffset value we just
+	 * 1. This multixact may be the latest one created, in which case there is
+	 * no next one to look at.	In this case the nextOffset value we just
 	 * saved is the correct endpoint.
 	 *
-	 * 2. The next multixact may still be in process of being filled in:
-	 * that is, another process may have done GetNewMultiXactId but not yet
-	 * written the offset entry for that ID.  In that scenario, it is
-	 * guaranteed that the offset entry for that multixact exists (because
-	 * GetNewMultiXactId won't release MultiXactGenLock until it does)
-	 * but contains zero (because we are careful to pre-zero offset pages).
-	 * Because GetNewMultiXactId will never return zero as the starting offset
-	 * for a multixact, when we read zero as the next multixact's offset, we
-	 * know we have this case.  We sleep for a bit and try again.
+	 * 2. The next multixact may still be in process of being filled in: that
+	 * is, another process may have done GetNewMultiXactId but not yet written
+	 * the offset entry for that ID.  In that scenario, it is guaranteed that
+	 * the offset entry for that multixact exists (because GetNewMultiXactId
+	 * won't release MultiXactGenLock until it does) but contains zero
+	 * (because we are careful to pre-zero offset pages). Because
+	 * GetNewMultiXactId will never return zero as the starting offset for a
+	 * multixact, when we read zero as the next multixact's offset, we know we
+	 * have this case.	We sleep for a bit and try again.
 	 *
-	 * 3. Because GetNewMultiXactId increments offset zero to offset one
-	 * to handle case #2, there is an ambiguity near the point of offset
-	 * wraparound.  If we see next multixact's offset is one, is that our
+	 * 3. Because GetNewMultiXactId increments offset zero to offset one to
+	 * handle case #2, there is an ambiguity near the point of offset
+	 * wraparound.	If we see next multixact's offset is one, is that our
 	 * multixact's actual endpoint, or did it end at zero with a subsequent
 	 * increment?  We handle this using the knowledge that if the zero'th
 	 * member slot wasn't filled, it'll contain zero, and zero isn't a valid
diff --git a/src/backend/access/transam/slru.c b/src/backend/access/transam/slru.c
index b8273d84f59..041c6cf84e0 100644
--- a/src/backend/access/transam/slru.c
+++ b/src/backend/access/transam/slru.c
@@ -42,7 +42,7 @@
  * Portions Copyright (c) 1996-2005, PostgreSQL Global Development Group
  * Portions Copyright (c) 1994, Regents of the University of California
  *
- * $PostgreSQL: pgsql/src/backend/access/transam/slru.c,v 1.29 2005/11/03 00:23:36 tgl Exp $
+ * $PostgreSQL: pgsql/src/backend/access/transam/slru.c,v 1.29.2.1 2005/11/22 18:23:05 momjian Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -278,7 +278,7 @@ SimpleLruReadPage(SlruCtl ctl, int pageno, TransactionId xid)
 		SlruRecentlyUsed(shared, slotno);
 
 		/*
-		 * We must grab the per-buffer lock to do I/O.  To avoid deadlock,
+		 * We must grab the per-buffer lock to do I/O.	To avoid deadlock,
 		 * must release ControlLock while waiting for per-buffer lock.
 		 * Fortunately, most of the time the per-buffer lock shouldn't be
 		 * already held, so we can do this:
@@ -352,10 +352,10 @@ SimpleLruWritePage(SlruCtl ctl, int slotno, SlruFlush fdata)
 	pageno = shared->page_number[slotno];
 
 	/*
-	 * We must grab the per-buffer lock to do I/O.  To avoid deadlock,
-	 * must release ControlLock while waiting for per-buffer lock.
-	 * Fortunately, most of the time the per-buffer lock shouldn't be
-	 * already held, so we can do this:
+	 * We must grab the per-buffer lock to do I/O.	To avoid deadlock, must
+	 * release ControlLock while waiting for per-buffer lock. Fortunately,
+	 * most of the time the per-buffer lock shouldn't be already held, so we
+	 * can do this:
 	 */
 	if (!LWLockConditionalAcquire(shared->buffer_locks[slotno],
 								  LW_EXCLUSIVE))
@@ -754,8 +754,8 @@ SlruSelectLRUPage(SlruCtl ctl, int pageno)
 		/*
 		 * We need to do I/O.  Normal case is that we have to write it out,
 		 * but it's possible in the worst case to have selected a read-busy
-		 * page.  In that case we just wait for someone else to complete
-		 * the I/O, which we can do by waiting for the per-buffer lock.
+		 * page.  In that case we just wait for someone else to complete the
+		 * I/O, which we can do by waiting for the per-buffer lock.
 		 */
 		if (shared->page_status[bestslot] == SLRU_PAGE_READ_IN_PROGRESS)
 		{
diff --git a/src/backend/access/transam/subtrans.c b/src/backend/access/transam/subtrans.c
index 7671eb6a45e..3c111e62c66 100644
--- a/src/backend/access/transam/subtrans.c
+++ b/src/backend/access/transam/subtrans.c
@@ -22,7 +22,7 @@
  * Portions Copyright (c) 1996-2005, PostgreSQL Global Development Group
  * Portions Copyright (c) 1994, Regents of the University of California
  *
- * $PostgreSQL: pgsql/src/backend/access/transam/subtrans.c,v 1.11 2005/10/15 02:49:09 momjian Exp $
+ * $PostgreSQL: pgsql/src/backend/access/transam/subtrans.c,v 1.11.2.1 2005/11/22 18:23:05 momjian Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -261,8 +261,8 @@ ShutdownSUBTRANS(void)
 	/*
 	 * Flush dirty SUBTRANS pages to disk
 	 *
-	 * This is not actually necessary from a correctness point of view. We do it
-	 * merely as a debugging aid.
+	 * This is not actually necessary from a correctness point of view. We do
+	 * it merely as a debugging aid.
 	 */
 	SimpleLruFlush(SubTransCtl, false);
 }
@@ -276,9 +276,9 @@ CheckPointSUBTRANS(void)
 	/*
 	 * Flush dirty SUBTRANS pages to disk
 	 *
-	 * This is not actually necessary from a correctness point of view. We do it
-	 * merely to improve the odds that writing of dirty pages is done by the
-	 * checkpoint process and not by backends.
+	 * This is not actually necessary from a correctness point of view. We do
+	 * it merely to improve the odds that writing of dirty pages is done by
+	 * the checkpoint process and not by backends.
 	 */
 	SimpleLruFlush(SubTransCtl, true);
 }
diff --git a/src/backend/access/transam/transam.c b/src/backend/access/transam/transam.c
index 59852520521..ed6c4bb608c 100644
--- a/src/backend/access/transam/transam.c
+++ b/src/backend/access/transam/transam.c
@@ -8,7 +8,7 @@
  *
  *
  * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/access/transam/transam.c,v 1.66 2005/10/15 02:49:09 momjian Exp $
+ *	  $PostgreSQL: pgsql/src/backend/access/transam/transam.c,v 1.66.2.1 2005/11/22 18:23:05 momjian Exp $
  *
  * NOTES
  *	  This file contains the high level access-method interface to the
@@ -174,9 +174,9 @@ TransactionIdDidCommit(TransactionId transactionId)
 	 * pg_subtrans; instead assume that the parent crashed without cleaning up
 	 * its children.
 	 *
-	 * Originally we Assert'ed that the result of SubTransGetParent was not zero.
-	 * However with the introduction of prepared transactions, there can be a
-	 * window just after database startup where we do not have complete
+	 * Originally we Assert'ed that the result of SubTransGetParent was not
+	 * zero. However with the introduction of prepared transactions, there can
+	 * be a window just after database startup where we do not have complete
 	 * knowledge in pg_subtrans of the transactions after TransactionXmin.
 	 * StartupSUBTRANS() has ensured that any missing information will be
 	 * zeroed.	Since this case should not happen under normal conditions, it
diff --git a/src/backend/access/transam/twophase.c b/src/backend/access/transam/twophase.c
index 5423060653d..ca44e19a8ef 100644
--- a/src/backend/access/transam/twophase.c
+++ b/src/backend/access/transam/twophase.c
@@ -7,7 +7,7 @@
  * Portions Copyright (c) 1994, Regents of the University of California
  *
  * IDENTIFICATION
- *		$PostgreSQL: pgsql/src/backend/access/transam/twophase.c,v 1.16 2005/10/29 00:31:50 petere Exp $
+ *		$PostgreSQL: pgsql/src/backend/access/transam/twophase.c,v 1.16.2.1 2005/11/22 18:23:05 momjian Exp $
  *
  * NOTES
  *		Each global transaction is associated with a global transaction
@@ -851,10 +851,10 @@ EndPrepare(GlobalTransaction gxact)
 	/*
 	 * Create the 2PC state file.
 	 *
-	 * Note: because we use BasicOpenFile(), we are responsible for ensuring the
-	 * FD gets closed in any error exit path.  Once we get into the critical
-	 * section, though, it doesn't matter since any failure causes PANIC
-	 * anyway.
+	 * Note: because we use BasicOpenFile(), we are responsible for ensuring
+	 * the FD gets closed in any error exit path.  Once we get into the
+	 * critical section, though, it doesn't matter since any failure causes
+	 * PANIC anyway.
 	 */
 	TwoPhaseFilePath(path, xid);
 
@@ -911,8 +911,8 @@ EndPrepare(GlobalTransaction gxact)
 	 * The state file isn't valid yet, because we haven't written the correct
 	 * CRC yet.  Before we do that, insert entry in WAL and flush it to disk.
 	 *
-	 * Between the time we have written the WAL entry and the time we write out
-	 * the correct state file CRC, we have an inconsistency: the xact is
+	 * Between the time we have written the WAL entry and the time we write
+	 * out the correct state file CRC, we have an inconsistency: the xact is
 	 * prepared according to WAL but not according to our on-disk state. We
 	 * use a critical section to force a PANIC if we are unable to complete
 	 * the write --- then, WAL replay should repair the inconsistency.	The
@@ -1344,11 +1344,11 @@ CheckPointTwoPhase(XLogRecPtr redo_horizon)
 	 * it just long enough to make a list of the XIDs that require fsyncing,
 	 * and then do the I/O afterwards.
 	 *
-	 * This approach creates a race condition: someone else could delete a GXACT
-	 * between the time we release TwoPhaseStateLock and the time we try to
-	 * open its state file.  We handle this by special-casing ENOENT failures:
-	 * if we see that, we verify that the GXACT is no longer valid, and if so
-	 * ignore the failure.
+	 * This approach creates a race condition: someone else could delete a
+	 * GXACT between the time we release TwoPhaseStateLock and the time we try
+	 * to open its state file.	We handle this by special-casing ENOENT
+	 * failures: if we see that, we verify that the GXACT is no longer valid,
+	 * and if so ignore the failure.
 	 */
 	if (max_prepared_xacts <= 0)
 		return;					/* nothing to do */
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 874a9736c70..21c0e069219 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -6,7 +6,7 @@
  * Copyright (c) 2000-2005, PostgreSQL Global Development Group
  *
  * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/access/transam/varsup.c,v 1.68 2005/10/29 00:31:50 petere Exp $
+ *	  $PostgreSQL: pgsql/src/backend/access/transam/varsup.c,v 1.68.2.1 2005/11/22 18:23:05 momjian Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -56,8 +56,8 @@ GetNewTransactionId(bool isSubXact)
 	 * (which gives an escape hatch to the DBA who ignored all those
 	 * warnings).
 	 *
-	 * Test is coded to fall out as fast as possible during normal operation, ie,
-	 * when the warn limit is set and we haven't violated it.
+	 * Test is coded to fall out as fast as possible during normal operation,
+	 * ie, when the warn limit is set and we haven't violated it.
 	 */
 	if (TransactionIdFollowsOrEquals(xid, ShmemVariableCache->xidWarnLimit) &&
 		TransactionIdIsValid(ShmemVariableCache->xidWarnLimit))
@@ -268,8 +268,8 @@ GetNewObjectId(void)
 	 * right after a wrap occurs, so as to avoid a possibly large number of
 	 * iterations in GetNewOid.)  Note we are relying on unsigned comparison.
 	 *
-	 * During initdb, we start the OID generator at FirstBootstrapObjectId, so we
-	 * only enforce wrapping to that point when in bootstrap or standalone
+	 * During initdb, we start the OID generator at FirstBootstrapObjectId, so
+	 * we only enforce wrapping to that point when in bootstrap or standalone
 	 * mode.  The first time through this routine after normal postmaster
 	 * start, the counter will be forced up to FirstNormalObjectId. This
 	 * mechanism leaves the OIDs between FirstBootstrapObjectId and
diff --git a/src/backend/access/transam/xact.c b/src/backend/access/transam/xact.c
index ea19e075640..a1bac34e168 100644
--- a/src/backend/access/transam/xact.c
+++ b/src/backend/access/transam/xact.c
@@ -10,7 +10,7 @@
  *
  *
  * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/access/transam/xact.c,v 1.215 2005/10/15 02:49:09 momjian Exp $
+ *	  $PostgreSQL: pgsql/src/backend/access/transam/xact.c,v 1.215.2.1 2005/11/22 18:23:05 momjian Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -750,8 +750,8 @@ RecordTransactionCommit(void)
 		 * XLOG record generated by nextval will hit the disk before we report
 		 * the transaction committed.
 		 *
-		 * Note: if we generated a commit record above, MyXactMadeXLogEntry will
-		 * certainly be set now.
+		 * Note: if we generated a commit record above, MyXactMadeXLogEntry
+		 * will certainly be set now.
 		 */
 		if (MyXactMadeXLogEntry)
 		{
@@ -762,8 +762,8 @@ RecordTransactionCommit(void)
 			 * because on most Unixen, the minimum select() delay is 10msec or
 			 * more, which is way too long.)
 			 *
-			 * We do not sleep if enableFsync is not turned on, nor if there are
-			 * fewer than CommitSiblings other backends with active
+			 * We do not sleep if enableFsync is not turned on, nor if there
+			 * are fewer than CommitSiblings other backends with active
 			 * transactions.
 			 */
 			if (CommitDelay > 0 && enableFsync &&
@@ -993,10 +993,10 @@ RecordTransactionAbort(void)
 		 * nowhere in permanent storage, so no one else will ever care if it
 		 * committed.)
 		 *
-		 * We do not flush XLOG to disk unless deleting files, since the default
-		 * assumption after a crash would be that we aborted, anyway. For the
-		 * same reason, we don't need to worry about interlocking against
-		 * checkpoint start.
+		 * We do not flush XLOG to disk unless deleting files, since the
+		 * default assumption after a crash would be that we aborted, anyway.
+		 * For the same reason, we don't need to worry about interlocking
+		 * against checkpoint start.
 		 */
 		if (MyLastRecPtr.xrecoff != 0 || nrels > 0)
 		{
@@ -1042,8 +1042,8 @@ RecordTransactionAbort(void)
 		 * Mark the transaction aborted in clog.  This is not absolutely
 		 * necessary but we may as well do it while we are here.
 		 *
-		 * The ordering here isn't critical but it seems best to mark the parent
-		 * first.  This assures an atomic transition of all the
+		 * The ordering here isn't critical but it seems best to mark the
+		 * parent first.  This assures an atomic transition of all the
 		 * subtransactions to aborted state from the point of view of
 		 * concurrent TransactionIdDidAbort calls.
 		 */
@@ -1520,11 +1520,11 @@ CommitTransaction(void)
 	 * it's too late to abort the transaction.  This should be just
 	 * noncritical resource releasing.
 	 *
-	 * The ordering of operations is not entirely random.  The idea is: release
-	 * resources visible to other backends (eg, files, buffer pins); then
-	 * release locks; then release backend-local resources. We want to release
-	 * locks at the point where any backend waiting for us will see our
-	 * transaction as being fully cleaned up.
+	 * The ordering of operations is not entirely random.  The idea is:
+	 * release resources visible to other backends (eg, files, buffer pins);
+	 * then release locks; then release backend-local resources. We want to
+	 * release locks at the point where any backend waiting for us will see
+	 * our transaction as being fully cleaned up.
 	 *
 	 * Resources that can be associated with individual queries are handled by
 	 * the ResourceOwner mechanism.  The other calls here are for backend-wide
@@ -1630,9 +1630,9 @@ PrepareTransaction(void)
 	 * Do pre-commit processing (most of this stuff requires database access,
 	 * and in fact could still cause an error...)
 	 *
-	 * It is possible for PrepareHoldablePortals to invoke functions that queue
-	 * deferred triggers, and it's also possible that triggers create holdable
-	 * cursors.  So we have to loop until there's nothing left to do.
+	 * It is possible for PrepareHoldablePortals to invoke functions that
+	 * queue deferred triggers, and it's also possible that triggers create
+	 * holdable cursors.  So we have to loop until there's nothing left to do.
 	 */
 	for (;;)
 	{
@@ -1715,9 +1715,9 @@ PrepareTransaction(void)
 	/*
 	 * Here is where we really truly prepare.
 	 *
-	 * We have to record transaction prepares even if we didn't make any updates,
-	 * because the transaction manager might get confused if we lose a global
-	 * transaction.
+	 * We have to record transaction prepares even if we didn't make any
+	 * updates, because the transaction manager might get confused if we lose
+	 * a global transaction.
 	 */
 	EndPrepare(gxact);
 
@@ -1868,10 +1868,11 @@ AbortTransaction(void)
 	 * s->currentUser, since it may not be set yet; instead rely on internal
 	 * state of miscinit.c.
 	 *
-	 * (Note: it is not necessary to restore session authorization here because
-	 * that can only be changed via GUC, and GUC will take care of rolling it
-	 * back if need be.  However, an error within a SECURITY DEFINER function
-	 * could send control here with the wrong current userid.)
+	 * (Note: it is not necessary to restore session authorization here
+	 * because that can only be changed via GUC, and GUC will take care of
+	 * rolling it back if need be.	However, an error within a SECURITY
+	 * DEFINER function could send control here with the wrong current
+	 * userid.)
 	 */
 	AtAbort_UserId();
 
@@ -2353,8 +2354,8 @@ AbortCurrentTransaction(void)
 
 			/*
 			 * Here, we are already in an aborted transaction state and are
-			 * waiting for a ROLLBACK, but for some reason we failed again!
-			 * So we just remain in the abort state.
+			 * waiting for a ROLLBACK, but for some reason we failed again! So
+			 * we just remain in the abort state.
 			 */
 		case TBLOCK_ABORT:
 		case TBLOCK_SUBABORT:
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index 66db5d9dd26..5722540b0c2 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -7,7 +7,7 @@
  * Portions Copyright (c) 1996-2005, PostgreSQL Global Development Group
  * Portions Copyright (c) 1994, Regents of the University of California
  *
- * $PostgreSQL: pgsql/src/backend/access/transam/xlog.c,v 1.222 2005/10/29 00:31:50 petere Exp $
+ * $PostgreSQL: pgsql/src/backend/access/transam/xlog.c,v 1.222.2.1 2005/11/22 18:23:05 momjian Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -571,11 +571,11 @@ XLogInsert(RmgrId rmid, uint8 info, XLogRecData *rdata)
 	 * the whole record in the order "rdata, then backup blocks, then record
 	 * header".
 	 *
-	 * We may have to loop back to here if a race condition is detected below. We
-	 * could prevent the race by doing all this work while holding the insert
-	 * lock, but it seems better to avoid doing CRC calculations while holding
-	 * the lock.  This means we have to be careful about modifying the rdata
-	 * chain until we know we aren't going to loop back again.  The only
+	 * We may have to loop back to here if a race condition is detected below.
+	 * We could prevent the race by doing all this work while holding the
+	 * insert lock, but it seems better to avoid doing CRC calculations while
+	 * holding the lock.  This means we have to be careful about modifying the
+	 * rdata chain until we know we aren't going to loop back again.  The only
 	 * change we allow ourselves to make earlier is to set rdt->data = NULL in
 	 * chain items we have decided we will have to back up the whole buffer
 	 * for.  This is OK because we will certainly decide the same thing again
@@ -763,9 +763,9 @@ begin:;
 	 * now irrevocably changed the input rdata chain.  At the exit of this
 	 * loop, write_len includes the backup block data.
 	 *
-	 * Also set the appropriate info bits to show which buffers were backed up.
-	 * The i'th XLR_SET_BKP_BLOCK bit corresponds to the i'th distinct buffer
-	 * value (ignoring InvalidBuffer) appearing in the rdata chain.
+	 * Also set the appropriate info bits to show which buffers were backed
+	 * up. The i'th XLR_SET_BKP_BLOCK bit corresponds to the i'th distinct
+	 * buffer value (ignoring InvalidBuffer) appearing in the rdata chain.
 	 */
 	write_len = len;
 	for (i = 0; i < XLR_MAX_BKP_BLOCKS; i++)
@@ -1666,20 +1666,20 @@ XLogFlush(XLogRecPtr record)
 	 * problem; most likely, the requested flush point is past end of XLOG.
 	 * This has been seen to occur when a disk page has a corrupted LSN.
 	 *
-	 * Formerly we treated this as a PANIC condition, but that hurts the system's
-	 * robustness rather than helping it: we do not want to take down the
-	 * whole system due to corruption on one data page.  In particular, if the
-	 * bad page is encountered again during recovery then we would be unable
-	 * to restart the database at all!	(This scenario has actually happened
-	 * in the field several times with 7.1 releases. Note that we cannot get
-	 * here while InRedo is true, but if the bad page is brought in and marked
-	 * dirty during recovery then CreateCheckPoint will try to flush it at the
-	 * end of recovery.)
+	 * Formerly we treated this as a PANIC condition, but that hurts the
+	 * system's robustness rather than helping it: we do not want to take down
+	 * the whole system due to corruption on one data page.  In particular, if
+	 * the bad page is encountered again during recovery then we would be
+	 * unable to restart the database at all!  (This scenario has actually
+	 * happened in the field several times with 7.1 releases. Note that we
+	 * cannot get here while InRedo is true, but if the bad page is brought in
+	 * and marked dirty during recovery then CreateCheckPoint will try to
+	 * flush it at the end of recovery.)
 	 *
-	 * The current approach is to ERROR under normal conditions, but only WARNING
-	 * during recovery, so that the system can be brought up even if there's a
-	 * corrupt LSN.  Note that for calls from xact.c, the ERROR will be
-	 * promoted to PANIC since xact.c calls this routine inside a critical
+	 * The current approach is to ERROR under normal conditions, but only
+	 * WARNING during recovery, so that the system can be brought up even if
+	 * there's a corrupt LSN.  Note that for calls from xact.c, the ERROR will
+	 * be promoted to PANIC since xact.c calls this routine inside a critical
 	 * section.  However, calls from bufmgr.c are not within critical sections
 	 * and so we will not force a restart for a bad LSN on a data page.
 	 */
@@ -2152,14 +2152,14 @@ RestoreArchivedFile(char *path, const char *xlogfname,
 	 * preserved correctly when we copied to archive. Our aim is robustness,
 	 * so we elect not to do this.
 	 *
-	 * If we cannot obtain the log file from the archive, however, we will try to
-	 * use the XLOGDIR file if it exists.  This is so that we can make use of
-	 * log segments that weren't yet transferred to the archive.
+	 * If we cannot obtain the log file from the archive, however, we will try
+	 * to use the XLOGDIR file if it exists.  This is so that we can make use
+	 * of log segments that weren't yet transferred to the archive.
 	 *
-	 * Notice that we don't actually overwrite any files when we copy back from
-	 * archive because the recoveryRestoreCommand may inadvertently restore
-	 * inappropriate xlogs, or they may be corrupt, so we may wish to fallback
-	 * to the segments remaining in current XLOGDIR later. The
+	 * Notice that we don't actually overwrite any files when we copy back
+	 * from archive because the recoveryRestoreCommand may inadvertently
+	 * restore inappropriate xlogs, or they may be corrupt, so we may wish to
+	 * fallback to the segments remaining in current XLOGDIR later. The
 	 * copy-from-archive filename is always the same, ensuring that we don't
 	 * run out of disk space on long recoveries.
 	 */
@@ -2246,11 +2246,11 @@ RestoreArchivedFile(char *path, const char *xlogfname,
 		 * command apparently succeeded, but let's make sure the file is
 		 * really there now and has the correct size.
 		 *
-		 * XXX I made wrong-size a fatal error to ensure the DBA would notice it,
-		 * but is that too strong?	We could try to plow ahead with a local
-		 * copy of the file ... but the problem is that there probably isn't
-		 * one, and we'd incorrectly conclude we've reached the end of WAL and
-		 * we're done recovering ...
+		 * XXX I made wrong-size a fatal error to ensure the DBA would notice
+		 * it, but is that too strong?	We could try to plow ahead with a
+		 * local copy of the file ... but the problem is that there probably
+		 * isn't one, and we'd incorrectly conclude we've reached the end of
+		 * WAL and we're done recovering ...
 		 */
 		if (stat(xlogpath, &stat_buf) == 0)
 		{
@@ -3533,8 +3533,8 @@ ReadControlFile(void)
 	/*
 	 * Do compatibility checking immediately.  We do this here for 2 reasons:
 	 *
-	 * (1) if the database isn't compatible with the backend executable, we want
-	 * to abort before we can possibly do any damage;
+	 * (1) if the database isn't compatible with the backend executable, we
+	 * want to abort before we can possibly do any damage;
 	 *
 	 * (2) this code is executed in the postmaster, so the setlocale() will
 	 * propagate to forked backends, which aren't going to read this file for
@@ -4148,9 +4148,9 @@ exitArchiveRecovery(TimeLineID endTLI, uint32 endLogId, uint32 endLogSeg)
 	 * descriptive of what our current database state is, because that is what
 	 * we replayed from.
 	 *
-	 * Note that if we are establishing a new timeline, ThisTimeLineID is already
-	 * set to the new value, and so we will create a new file instead of
-	 * overwriting any existing file.
+	 * Note that if we are establishing a new timeline, ThisTimeLineID is
+	 * already set to the new value, and so we will create a new file instead
+	 * of overwriting any existing file.
 	 */
 	snprintf(recoveryPath, MAXPGPATH, XLOGDIR "/RECOVERYXLOG");
 	XLogFilePath(xlogpath, ThisTimeLineID, endLogId, endLogSeg);
@@ -4341,8 +4341,8 @@ StartupXLOG(void)
 	/*
 	 * Read control file and check XLOG status looks valid.
 	 *
-	 * Note: in most control paths, *ControlFile is already valid and we need not
-	 * do ReadControlFile() here, but might as well do it to be sure.
+	 * Note: in most control paths, *ControlFile is already valid and we need
+	 * not do ReadControlFile() here, but might as well do it to be sure.
 	 */
 	ReadControlFile();
 
@@ -4766,14 +4766,14 @@ StartupXLOG(void)
 		/*
 		 * Perform a new checkpoint to update our recovery activity to disk.
 		 *
-		 * Note that we write a shutdown checkpoint rather than an on-line one.
-		 * This is not particularly critical, but since we may be assigning a
-		 * new TLI, using a shutdown checkpoint allows us to have the rule
-		 * that TLI only changes in shutdown checkpoints, which allows some
-		 * extra error checking in xlog_redo.
+		 * Note that we write a shutdown checkpoint rather than an on-line
+		 * one. This is not particularly critical, but since we may be
+		 * assigning a new TLI, using a shutdown checkpoint allows us to have
+		 * the rule that TLI only changes in shutdown checkpoints, which
+		 * allows some extra error checking in xlog_redo.
 		 *
-		 * In case we had to use the secondary checkpoint, make sure that it will
-		 * still be shown as the secondary checkpoint after this
+		 * In case we had to use the secondary checkpoint, make sure that it
+		 * will still be shown as the secondary checkpoint after this
 		 * CreateCheckPoint operation; we don't want the broken primary
 		 * checkpoint to become prevCheckPoint...
 		 */
@@ -5106,10 +5106,10 @@ CreateCheckPoint(bool shutdown, bool force)
 	 * (Perhaps it'd make even more sense to checkpoint only when the previous
 	 * checkpoint record is in a different xlog page?)
 	 *
-	 * We have to make two tests to determine that nothing has happened since the
-	 * start of the last checkpoint: current insertion point must match the
-	 * end of the last checkpoint record, and its redo pointer must point to
-	 * itself.
+	 * We have to make two tests to determine that nothing has happened since
+	 * the start of the last checkpoint: current insertion point must match
+	 * the end of the last checkpoint record, and its redo pointer must point
+	 * to itself.
 	 */
 	if (!shutdown && !force)
 	{
@@ -5198,11 +5198,11 @@ CreateCheckPoint(bool shutdown, bool force)
 	 * Having constructed the checkpoint record, ensure all shmem disk buffers
 	 * and commit-log buffers are flushed to disk.
 	 *
-	 * This I/O could fail for various reasons.  If so, we will fail to complete
-	 * the checkpoint, but there is no reason to force a system panic.
-	 * Accordingly, exit critical section while doing it.  (If we are doing a
-	 * shutdown checkpoint, we probably *should* panic --- but that will
-	 * happen anyway because we'll still be inside the critical section
+	 * This I/O could fail for various reasons.  If so, we will fail to
+	 * complete the checkpoint, but there is no reason to force a system
+	 * panic. Accordingly, exit critical section while doing it.  (If we are
+	 * doing a shutdown checkpoint, we probably *should* panic --- but that
+	 * will happen anyway because we'll still be inside the critical section
 	 * established by ShutdownXLOG.)
 	 */
 	END_CRIT_SECTION();