Run pgindent on 9.2 source tree in preparation for first 9.3

commit-fest.

1 files changed, 20 insertions, 20 deletions

diff --git a/src/backend/access/heap/visibilitymap.c b/src/backend/access/heap/visibilitymap.c
index 9152c7d1511..eb5625906f1 100644
--- a/src/backend/access/heap/visibilitymap.c
+++ b/src/backend/access/heap/visibilitymap.c
@@ -16,7 +16,7 @@
  *		visibilitymap_pin_ok - check whether correct map page is already pinned
  *		visibilitymap_set	 - set a bit in a previously pinned page
  *		visibilitymap_test	 - test if a bit is set
- *		visibilitymap_count	 - count number of bits set in visibility map
+ *		visibilitymap_count  - count number of bits set in visibility map
  *		visibilitymap_truncate	- truncate the visibility map
  *
  * NOTES
@@ -27,7 +27,7 @@
  * the sense that we make sure that whenever a bit is set, we know the
  * condition is true, but if a bit is not set, it might or might not be true.
  *
- * Clearing a visibility map bit is not separately WAL-logged.  The callers
+ * Clearing a visibility map bit is not separately WAL-logged.	The callers
  * must make sure that whenever a bit is cleared, the bit is cleared on WAL
  * replay of the updating operation as well.
  *
@@ -36,9 +36,9 @@
  * it may still be the case that every tuple on the page is visible to all
  * transactions; we just don't know that for certain.  The difficulty is that
  * there are two bits which are typically set together: the PD_ALL_VISIBLE bit
- * on the page itself, and the visibility map bit.  If a crash occurs after the
+ * on the page itself, and the visibility map bit.	If a crash occurs after the
  * visibility map page makes it to disk and before the updated heap page makes
- * it to disk, redo must set the bit on the heap page.  Otherwise, the next
+ * it to disk, redo must set the bit on the heap page.	Otherwise, the next
  * insert, update, or delete on the heap page will fail to realize that the
  * visibility map bit must be cleared, possibly causing index-only scans to
  * return wrong answers.
@@ -59,10 +59,10 @@
  * the buffer lock over any I/O that may be required to read in the visibility
  * map page.  To avoid this, we examine the heap page before locking it;
  * if the page-level PD_ALL_VISIBLE bit is set, we pin the visibility map
- * bit.  Then, we lock the buffer.  But this creates a race condition: there
+ * bit.  Then, we lock the buffer.	But this creates a race condition: there
  * is a possibility that in the time it takes to lock the buffer, the
  * PD_ALL_VISIBLE bit gets set.  If that happens, we have to unlock the
- * buffer, pin the visibility map page, and relock the buffer.  This shouldn't
+ * buffer, pin the visibility map page, and relock the buffer.	This shouldn't
  * happen often, because only VACUUM currently sets visibility map bits,
  * and the race will only occur if VACUUM processes a given page at almost
  * exactly the same time that someone tries to further modify it.
@@ -227,9 +227,9 @@ visibilitymap_pin_ok(BlockNumber heapBlk, Buffer buf)
  *	visibilitymap_set - set a bit on a previously pinned page
  *
  * recptr is the LSN of the XLOG record we're replaying, if we're in recovery,
- * or InvalidXLogRecPtr in normal running.  The page LSN is advanced to the
+ * or InvalidXLogRecPtr in normal running.	The page LSN is advanced to the
  * one provided; in normal running, we generate a new XLOG record and set the
- * page LSN to that value.  cutoff_xid is the largest xmin on the page being
+ * page LSN to that value.	cutoff_xid is the largest xmin on the page being
  * marked all-visible; it is needed for Hot Standby, and can be
  * InvalidTransactionId if the page contains no tuples.
  *
@@ -295,10 +295,10 @@ visibilitymap_set(Relation rel, BlockNumber heapBlk, XLogRecPtr recptr,
  * releasing *buf after it's done testing and setting bits.
  *
  * NOTE: This function is typically called without a lock on the heap page,
- * so somebody else could change the bit just after we look at it.  In fact,
+ * so somebody else could change the bit just after we look at it.	In fact,
  * since we don't lock the visibility map page either, it's even possible that
  * someone else could have changed the bit just before we look at it, but yet
- * we might see the old value.  It is the caller's responsibility to deal with
+ * we might see the old value.	It is the caller's responsibility to deal with
  * all concurrency issues!
  */
 bool
@@ -344,7 +344,7 @@ visibilitymap_test(Relation rel, BlockNumber heapBlk, Buffer *buf)
 }
 
 /*
- *	visibilitymap_count	 - count number of bits set in visibility map
+ *	visibilitymap_count  - count number of bits set in visibility map
  *
  * Note: we ignore the possibility of race conditions when the table is being
  * extended concurrently with the call.  New pages added to the table aren't
@@ -356,16 +356,16 @@ visibilitymap_count(Relation rel)
 	BlockNumber result = 0;
 	BlockNumber mapBlock;
 
-	for (mapBlock = 0; ; mapBlock++)
+	for (mapBlock = 0;; mapBlock++)
 	{
 		Buffer		mapBuffer;
 		unsigned char *map;
 		int			i;
 
 		/*
-		 * Read till we fall off the end of the map.  We assume that any
-		 * extra bytes in the last page are zeroed, so we don't bother
-		 * excluding them from the count.
+		 * Read till we fall off the end of the map.  We assume that any extra
+		 * bytes in the last page are zeroed, so we don't bother excluding
+		 * them from the count.
 		 */
 		mapBuffer = vm_readbuf(rel, mapBlock, false);
 		if (!BufferIsValid(mapBuffer))
@@ -496,11 +496,11 @@ vm_readbuf(Relation rel, BlockNumber blkno, bool extend)
 	Buffer		buf;
 
 	/*
-	 * We might not have opened the relation at the smgr level yet, or we might
-	 * have been forced to close it by a sinval message.  The code below won't
-	 * necessarily notice relation extension immediately when extend = false,
-	 * so we rely on sinval messages to ensure that our ideas about the size of
-	 * the map aren't too far out of date.
+	 * We might not have opened the relation at the smgr level yet, or we
+	 * might have been forced to close it by a sinval message.	The code below
+	 * won't necessarily notice relation extension immediately when extend =
+	 * false, so we rely on sinval messages to ensure that our ideas about the
+	 * size of the map aren't too far out of date.
 	 */
 	RelationOpenSmgr(rel);