pgindent run for 9.4

This includes removing tabs after periods in C comments, which was
applied to back branches, so this change should not effect backpatching.

src/backend/catalog/index.c

@@ -411,7 +411,7 @@ ConstructTupleDescriptor(Relation heapRelation,
 
 		/*
 		 * We do not yet have the correct relation OID for the index, so just
-		 * set it invalid for now.	InitializeAttributeOids() will fix it
+		 * set it invalid for now.  InitializeAttributeOids() will fix it
 		 * later.
 		 */
 		to->attrelid = InvalidOid;
@@ -651,7 +651,7 @@ UpdateIndexRelation(Oid indexoid,
  * heapRelation: table to build index on (suitably locked by caller)
  * indexRelationName: what it say
  * indexRelationId: normally, pass InvalidOid to let this routine
- *		generate an OID for the index.	During bootstrap this may be
+ *		generate an OID for the index.  During bootstrap this may be
  *		nonzero to specify a preselected OID.
  * relFileNode: normally, pass InvalidOid to get new storage.  May be
  *		nonzero to attach an existing valid build.
@@ -670,7 +670,7 @@ UpdateIndexRelation(Oid indexoid,
  * allow_system_table_mods: allow table to be a system catalog
  * skip_build: true to skip the index_build() step for the moment; caller
  *		must do it later (typically via reindex_index())
- * concurrent: if true, do not lock the table against writers.	The index
+ * concurrent: if true, do not lock the table against writers.  The index
  *		will be marked "invalid" and the caller must take additional steps
  *		to fix it up.
  * is_internal: if true, post creation hook for new index
@@ -960,7 +960,7 @@ index_create(Relation heapRelation,
 
 			/*
 			 * If there are no simply-referenced columns, give the index an
-			 * auto dependency on the whole table.	In most cases, this will
+			 * auto dependency on the whole table.  In most cases, this will
 			 * be redundant, but it might not be if the index expressions and
 			 * predicate contain no Vars or only whole-row Vars.
 			 */
@@ -1085,7 +1085,7 @@ index_create(Relation heapRelation,
 
 	/*
 	 * Close the index; but we keep the lock that we acquired above until end
-	 * of transaction.	Closing the heap is caller's responsibility.
+	 * of transaction.  Closing the heap is caller's responsibility.
 	 */
 	index_close(indexRelation, NoLock);
 
@@ -1243,7 +1243,7 @@ index_constraint_create(Relation heapRelation,
 	 * have been so marked already, so no need to clear the flag in the other
 	 * case.
 	 *
-	 * Note: this might better be done by callers.	We do it here to avoid
+	 * Note: this might better be done by callers.  We do it here to avoid
 	 * exposing index_update_stats() globally, but that wouldn't be necessary
 	 * if relhaspkey went away.
 	 */
@@ -1256,10 +1256,10 @@ index_constraint_create(Relation heapRelation,
 	/*
 	 * If needed, mark the index as primary and/or deferred in pg_index.
 	 *
-	 * Note: When making an existing index into a constraint, caller must
-	 * have a table lock that prevents concurrent table updates; otherwise,
-	 * there is a risk that concurrent readers of the table will miss seeing
-	 * this index at all.
+	 * Note: When making an existing index into a constraint, caller must have
+	 * a table lock that prevents concurrent table updates; otherwise, there
+	 * is a risk that concurrent readers of the table will miss seeing this
+	 * index at all.
 	 */
 	if (update_pgindex && (mark_as_primary || deferrable))
 	{
@@ -1336,7 +1336,7 @@ index_drop(Oid indexId, bool concurrent)
 	 * in multiple steps and waiting out any transactions that might be using
 	 * the index, so we don't need exclusive lock on the parent table. Instead
 	 * we take ShareUpdateExclusiveLock, to ensure that two sessions aren't
-	 * doing CREATE/DROP INDEX CONCURRENTLY on the same index.	(We will get
+	 * doing CREATE/DROP INDEX CONCURRENTLY on the same index.  (We will get
 	 * AccessExclusiveLock on the index below, once we're sure nobody else is
 	 * using it.)
 	 */
@@ -1376,7 +1376,7 @@ index_drop(Oid indexId, bool concurrent)
 	 * non-concurrent case we can just do that now.  In the concurrent case
 	 * it's a bit trickier.  The predicate locks must be moved when there are
 	 * no index scans in progress on the index and no more can subsequently
-	 * start, so that no new predicate locks can be made on the index.	Also,
+	 * start, so that no new predicate locks can be made on the index.  Also,
 	 * they must be moved before heap inserts stop maintaining the index, else
 	 * the conflict with the predicate lock on the index gap could be missed
 	 * before the lock on the heap relation is in place to detect a conflict
@@ -1386,11 +1386,11 @@ index_drop(Oid indexId, bool concurrent)
 	{
 		/*
 		 * We must commit our transaction in order to make the first pg_index
-		 * state update visible to other sessions.	If the DROP machinery has
+		 * state update visible to other sessions.  If the DROP machinery has
 		 * already performed any other actions (removal of other objects,
 		 * pg_depend entries, etc), the commit would make those actions
 		 * permanent, which would leave us with inconsistent catalog state if
-		 * we fail partway through the following sequence.	Since DROP INDEX
+		 * we fail partway through the following sequence.  Since DROP INDEX
 		 * CONCURRENTLY is restricted to dropping just one index that has no
 		 * dependencies, we should get here before anything's been done ---
 		 * but let's check that to be sure.  We can verify that the current
@@ -1426,7 +1426,7 @@ index_drop(Oid indexId, bool concurrent)
 		 * We must commit our current transaction so that the indisvalid
 		 * update becomes visible to other transactions; then start another.
 		 * Note that any previously-built data structures are lost in the
-		 * commit.	The only data we keep past here are the relation IDs.
+		 * commit.  The only data we keep past here are the relation IDs.
 		 *
 		 * Before committing, get a session-level lock on the table, to ensure
 		 * that neither it nor the index can be dropped before we finish. This
@@ -1443,10 +1443,10 @@ index_drop(Oid indexId, bool concurrent)
 		/*
 		 * Now we must wait until no running transaction could be using the
 		 * index for a query.  Use AccessExclusiveLock here to check for
-		 * running transactions that hold locks of any kind on the table.
-		 * Note we do not need to worry about xacts that open the table for
-		 * reading after this point; they will see the index as invalid when
-		 * they open the relation.
+		 * running transactions that hold locks of any kind on the table. Note
+		 * we do not need to worry about xacts that open the table for reading
+		 * after this point; they will see the index as invalid when they open
+		 * the relation.
 		 *
 		 * Note: the reason we use actual lock acquisition here, rather than
 		 * just checking the ProcArray and sleeping, is that deadlock is
@@ -1468,7 +1468,7 @@ index_drop(Oid indexId, bool concurrent)
 
 		/*
 		 * Now we are sure that nobody uses the index for queries; they just
-		 * might have it open for updating it.	So now we can unset indisready
+		 * might have it open for updating it.  So now we can unset indisready
 		 * and indislive, then wait till nobody could be using it at all
 		 * anymore.
 		 */
@@ -1599,7 +1599,7 @@ index_drop(Oid indexId, bool concurrent)
  *
  * IndexInfo stores the information about the index that's needed by
  * FormIndexDatum, which is used for both index_build() and later insertion
- * of individual index tuples.	Normally we build an IndexInfo for an index
+ * of individual index tuples.  Normally we build an IndexInfo for an index
  * just once per command, and then use it for (potentially) many tuples.
  * ----------------
  */
@@ -1669,7 +1669,7 @@ BuildIndexInfo(Relation index)
  * context must point to the heap tuple passed in.
  *
  * Notice we don't actually call index_form_tuple() here; we just prepare
- * its input arrays values[] and isnull[].	This is because the index AM
+ * its input arrays values[] and isnull[].  This is because the index AM
  * may wish to alter the data before storage.
  * ----------------
  */
@@ -1735,7 +1735,7 @@ FormIndexDatum(IndexInfo *indexInfo,
  * index_update_stats --- update pg_class entry after CREATE INDEX or REINDEX
  *
  * This routine updates the pg_class row of either an index or its parent
- * relation after CREATE INDEX or REINDEX.	Its rather bizarre API is designed
+ * relation after CREATE INDEX or REINDEX.  Its rather bizarre API is designed
  * to ensure we can do all the necessary work in just one update.
  *
  * hasindex: set relhasindex to this value
@@ -1747,7 +1747,7 @@ FormIndexDatum(IndexInfo *indexInfo,
  *
  * NOTE: an important side-effect of this operation is that an SI invalidation
  * message is sent out to all backends --- including me --- causing relcache
- * entries to be flushed or updated with the new data.	This must happen even
+ * entries to be flushed or updated with the new data.  This must happen even
  * if we find that no change is needed in the pg_class row.  When updating
  * a heap entry, this ensures that other backends find out about the new
  * index.  When updating an index, it's important because some index AMs
@@ -1786,13 +1786,13 @@ index_update_stats(Relation rel,
 	 * 4. Even with just a single CREATE INDEX, there's a risk factor because
 	 * someone else might be trying to open the rel while we commit, and this
 	 * creates a race condition as to whether he will see both or neither of
-	 * the pg_class row versions as valid.	Again, a non-transactional update
+	 * the pg_class row versions as valid.  Again, a non-transactional update
 	 * avoids the risk.  It is indeterminate which state of the row the other
 	 * process will see, but it doesn't matter (if he's only taking
 	 * AccessShareLock, then it's not critical that he see relhasindex true).
 	 *
 	 * It is safe to use a non-transactional update even though our
-	 * transaction could still fail before committing.	Setting relhasindex
+	 * transaction could still fail before committing.  Setting relhasindex
 	 * true is safe even if there are no indexes (VACUUM will eventually fix
 	 * it), likewise for relhaspkey.  And of course the new relpages and
 	 * reltuples counts are correct regardless.  However, we don't want to
@@ -1804,7 +1804,7 @@ index_update_stats(Relation rel,
 	pg_class = heap_open(RelationRelationId, RowExclusiveLock);
 
 	/*
-	 * Make a copy of the tuple to update.	Normally we use the syscache, but
+	 * Make a copy of the tuple to update.  Normally we use the syscache, but
 	 * we can't rely on that during bootstrap or while reindexing pg_class
 	 * itself.
 	 */
@@ -1903,7 +1903,7 @@ index_update_stats(Relation rel,
  * index_build - invoke access-method-specific index build procedure
  *
  * On entry, the index's catalog entries are valid, and its physical disk
- * file has been created but is empty.	We call the AM-specific build
+ * file has been created but is empty.  We call the AM-specific build
  * procedure to fill in the index contents.  We then update the pg_class
  * entries of the index and heap relation as needed, using statistics
  * returned by ambuild as well as data passed by the caller.
@@ -2001,7 +2001,7 @@ index_build(Relation heapRelation,
 	 * Therefore, this code path can only be taken during non-concurrent
 	 * CREATE INDEX.  Thus the fact that heap_update will set the pg_index
 	 * tuple's xmin doesn't matter, because that tuple was created in the
-	 * current transaction anyway.	That also means we don't need to worry
+	 * current transaction anyway.  That also means we don't need to worry
 	 * about any concurrent readers of the tuple; no other transaction can see
 	 * it yet.
 	 */
@@ -2050,7 +2050,7 @@ index_build(Relation heapRelation,
 
 	/*
 	 * If it's for an exclusion constraint, make a second pass over the heap
-	 * to verify that the constraint is satisfied.	We must not do this until
+	 * to verify that the constraint is satisfied.  We must not do this until
 	 * the index is fully valid.  (Broken HOT chains shouldn't matter, though;
 	 * see comments for IndexCheckExclusion.)
 	 */
@@ -2075,8 +2075,8 @@ index_build(Relation heapRelation,
  * things to add it to the new index.  After we return, the AM's index
  * build procedure does whatever cleanup it needs.
  *
- * The total count of heap tuples is returned.	This is for updating pg_class
- * statistics.	(It's annoying not to be able to do that here, but we want
+ * The total count of heap tuples is returned.  This is for updating pg_class
+ * statistics.  (It's annoying not to be able to do that here, but we want
  * to merge that update with others; see index_update_stats.)  Note that the
  * index AM itself must keep track of the number of index tuples; we don't do
  * so here because the AM might reject some of the tuples for its own reasons,
@@ -2126,7 +2126,7 @@ IndexBuildHeapScan(Relation heapRelation,
 
 	/*
 	 * Need an EState for evaluation of index expressions and partial-index
-	 * predicates.	Also a slot to hold the current tuple.
+	 * predicates.  Also a slot to hold the current tuple.
 	 */
 	estate = CreateExecutorState();
 	econtext = GetPerTupleExprContext(estate);
@@ -2251,7 +2251,7 @@ IndexBuildHeapScan(Relation heapRelation,
 					 * building it, and may need to see such tuples.)
 					 *
 					 * However, if it was HOT-updated then we must only index
-					 * the live tuple at the end of the HOT-chain.	Since this
+					 * the live tuple at the end of the HOT-chain.  Since this
 					 * breaks semantics for pre-existing snapshots, mark the
 					 * index as unusable for them.
 					 */
@@ -2271,7 +2271,7 @@ IndexBuildHeapScan(Relation heapRelation,
 					/*
 					 * Since caller should hold ShareLock or better, normally
 					 * the only way to see this is if it was inserted earlier
-					 * in our own transaction.	However, it can happen in
+					 * in our own transaction.  However, it can happen in
 					 * system catalogs, since we tend to release write lock
 					 * before commit there.  Give a warning if neither case
 					 * applies.
@@ -2426,7 +2426,7 @@ IndexBuildHeapScan(Relation heapRelation,
 
 		/*
 		 * You'd think we should go ahead and build the index tuple here, but
-		 * some index AMs want to do further processing on the data first.	So
+		 * some index AMs want to do further processing on the data first.  So
 		 * pass the values[] and isnull[] arrays, instead.
 		 */
 
@@ -2517,7 +2517,7 @@ IndexCheckExclusion(Relation heapRelation,
 
 	/*
 	 * Need an EState for evaluation of index expressions and partial-index
-	 * predicates.	Also a slot to hold the current tuple.
+	 * predicates.  Also a slot to hold the current tuple.
 	 */
 	estate = CreateExecutorState();
 	econtext = GetPerTupleExprContext(estate);
@@ -2597,11 +2597,11 @@ IndexCheckExclusion(Relation heapRelation,
  * We do a concurrent index build by first inserting the catalog entry for the
  * index via index_create(), marking it not indisready and not indisvalid.
  * Then we commit our transaction and start a new one, then we wait for all
- * transactions that could have been modifying the table to terminate.	Now
+ * transactions that could have been modifying the table to terminate.  Now
  * we know that any subsequently-started transactions will see the index and
  * honor its constraints on HOT updates; so while existing HOT-chains might
  * be broken with respect to the index, no currently live tuple will have an
- * incompatible HOT update done to it.	We now build the index normally via
+ * incompatible HOT update done to it.  We now build the index normally via
  * index_build(), while holding a weak lock that allows concurrent
  * insert/update/delete.  Also, we index only tuples that are valid
  * as of the start of the scan (see IndexBuildHeapScan), whereas a normal
@@ -2615,13 +2615,13 @@ IndexCheckExclusion(Relation heapRelation,
  *
  * Next, we mark the index "indisready" (but still not "indisvalid") and
  * commit the second transaction and start a third.  Again we wait for all
- * transactions that could have been modifying the table to terminate.	Now
+ * transactions that could have been modifying the table to terminate.  Now
  * we know that any subsequently-started transactions will see the index and
  * insert their new tuples into it.  We then take a new reference snapshot
  * which is passed to validate_index().  Any tuples that are valid according
  * to this snap, but are not in the index, must be added to the index.
  * (Any tuples committed live after the snap will be inserted into the
- * index by their originating transaction.	Any tuples committed dead before
+ * index by their originating transaction.  Any tuples committed dead before
  * the snap need not be indexed, because we will wait out all transactions
  * that might care about them before we mark the index valid.)
  *
@@ -2630,7 +2630,7 @@ IndexCheckExclusion(Relation heapRelation,
  * ever say "delete it".  (This should be faster than a plain indexscan;
  * also, not all index AMs support full-index indexscan.)  Then we sort the
  * TIDs, and finally scan the table doing a "merge join" against the TID list
- * to see which tuples are missing from the index.	Thus we will ensure that
+ * to see which tuples are missing from the index.  Thus we will ensure that
  * all tuples valid according to the reference snapshot are in the index.
  *
  * Building a unique index this way is tricky: we might try to insert a
@@ -2646,7 +2646,7 @@ IndexCheckExclusion(Relation heapRelation,
  * were alive at the time of the reference snapshot are gone; this is
  * necessary to be sure there are none left with a transaction snapshot
  * older than the reference (and hence possibly able to see tuples we did
- * not index).	Then we mark the index "indisvalid" and commit.  Subsequent
+ * not index).  Then we mark the index "indisvalid" and commit.  Subsequent
  * transactions will be able to use it for queries.
  *
  * Doing two full table scans is a brute-force strategy.  We could try to be
@@ -2672,7 +2672,7 @@ validate_index(Oid heapId, Oid indexId, Snapshot snapshot)
 	indexRelation = index_open(indexId, RowExclusiveLock);
 
 	/*
-	 * Fetch info needed for index_insert.	(You might think this should be
+	 * Fetch info needed for index_insert.  (You might think this should be
 	 * passed in from DefineIndex, but its copy is long gone due to having
 	 * been built in a previous transaction.)
 	 */
@@ -2789,7 +2789,7 @@ validate_index_heapscan(Relation heapRelation,
 
 	/*
 	 * Need an EState for evaluation of index expressions and partial-index
-	 * predicates.	Also a slot to hold the current tuple.
+	 * predicates.  Also a slot to hold the current tuple.
 	 */
 	estate = CreateExecutorState();
 	econtext = GetPerTupleExprContext(estate);
@@ -2838,7 +2838,7 @@ validate_index_heapscan(Relation heapRelation,
 		 * visit the live tuples in order by their offsets, but the root
 		 * offsets that we need to compare against the index contents might be
 		 * ordered differently.  So we might have to "look back" within the
-		 * tuplesort output, but only within the current page.	We handle that
+		 * tuplesort output, but only within the current page.  We handle that
 		 * by keeping a bool array in_index[] showing all the
 		 * already-passed-over tuplesort output TIDs of the current page. We
 		 * clear that array here, when advancing onto a new heap page.
@@ -2923,7 +2923,7 @@ validate_index_heapscan(Relation heapRelation,
 
 			/*
 			 * For the current heap tuple, extract all the attributes we use
-			 * in this index, and note which are null.	This also performs
+			 * in this index, and note which are null.  This also performs
 			 * evaluation of any expressions needed.
 			 */
 			FormIndexDatum(indexInfo,
@@ -2945,7 +2945,7 @@ validate_index_heapscan(Relation heapRelation,
 			 * for a uniqueness check on the whole HOT-chain.  That is, the
 			 * tuple we have here could be dead because it was already
 			 * HOT-updated, and if so the updating transaction will not have
-			 * thought it should insert index entries.	The index AM will
+			 * thought it should insert index entries.  The index AM will
 			 * check the whole HOT-chain and correctly detect a conflict if
 			 * there is one.
 			 */
@@ -3068,7 +3068,7 @@ index_set_state_flags(Oid indexId, IndexStateFlagsAction action)
 
 /*
  * IndexGetRelation: given an index's relation OID, get the OID of the
- * relation it is an index on.	Uses the system cache.
+ * relation it is an index on.  Uses the system cache.
  */
 Oid
 IndexGetRelation(Oid indexId, bool missing_ok)
@@ -3105,7 +3105,7 @@ reindex_index(Oid indexId, bool skip_constraint_checks)
 	volatile bool skipped_constraint = false;
 
 	/*
-	 * Open and lock the parent heap relation.	ShareLock is sufficient since
+	 * Open and lock the parent heap relation.  ShareLock is sufficient since
 	 * we only need to be sure no schema or data changes are going on.
 	 */
 	heapId = IndexGetRelation(indexId, false);
@@ -3193,7 +3193,7 @@ reindex_index(Oid indexId, bool skip_constraint_checks)
 	 * chains, we had better force indcheckxmin true, because the normal
 	 * argument that the HOT chains couldn't conflict with the index is
 	 * suspect for an invalid index.  (A conflict is definitely possible if
-	 * the index was dead.	It probably shouldn't happen otherwise, but let's
+	 * the index was dead.  It probably shouldn't happen otherwise, but let's
 	 * be conservative.)  In this case advancing the usability horizon is
 	 * appropriate.
 	 *
@@ -3277,7 +3277,7 @@ reindex_index(Oid indexId, bool skip_constraint_checks)
  * the data in a manner that risks a change in constraint validity.
  *
  * Returns true if any indexes were rebuilt (including toast table's index
- * when relevant).	Note that a CommandCounterIncrement will occur after each
+ * when relevant).  Note that a CommandCounterIncrement will occur after each
  * index rebuild.
  */
 bool
@@ -3290,7 +3290,7 @@ reindex_relation(Oid relid, int flags)
 	bool		result;
 
 	/*
-	 * Open and lock the relation.	ShareLock is sufficient since we only need
+	 * Open and lock the relation.  ShareLock is sufficient since we only need
 	 * to prevent schema and data changes in it.  The lock level used here
 	 * should match ReindexTable().
 	 */
@@ -3309,7 +3309,7 @@ reindex_relation(Oid relid, int flags)
 	 * reindex_index will attempt to update the pg_class rows for the relation
 	 * and index.  If we are processing pg_class itself, we want to make sure
 	 * that the updates do not try to insert index entries into indexes we
-	 * have not processed yet.	(When we are trying to recover from corrupted
+	 * have not processed yet.  (When we are trying to recover from corrupted
 	 * indexes, that could easily cause a crash.) We can accomplish this
 	 * because CatalogUpdateIndexes will use the relcache's index list to know
 	 * which indexes to update. We just force the index list to be only the
@@ -3318,7 +3318,7 @@ reindex_relation(Oid relid, int flags)
 	 * It is okay to not insert entries into the indexes we have not processed
 	 * yet because all of this is transaction-safe.  If we fail partway
 	 * through, the updated rows are dead and it doesn't matter whether they
-	 * have index entries.	Also, a new pg_class index will be created with a
+	 * have index entries.  Also, a new pg_class index will be created with a
 	 * correct entry for its own pg_class row because we do
 	 * RelationSetNewRelfilenode() before we do index_build().
 	 *