Attached is a small patch to fix various typos.

Regards

Thom
diff --git a/contrib/pgcrypto/openssl.c b/contrib/pgcrypto/openssl.c
index ad7fb9e..86c0fb0 100644
--- a/contrib/pgcrypto/openssl.c
+++ b/contrib/pgcrypto/openssl.c
@@ -429,7 +429,7 @@ bf_init(PX_Cipher *c, const uint8 *key, unsigned klen, const uint8 *iv)
 
 	/*
 	 * Test if key len is supported. BF_set_key silently cut large keys and it
-	 * could be be a problem when user transfer crypted data from one server
+	 * could be a problem when user transfer crypted data from one server
 	 * to another.
 	 */
 
diff --git a/doc/src/sgml/gin.sgml b/doc/src/sgml/gin.sgml
index 80fb4f3..561608f 100644
--- a/doc/src/sgml/gin.sgml
+++ b/doc/src/sgml/gin.sgml
@@ -270,7 +270,7 @@
        contains the corresponding query keys. Likewise, the function must
        return GIN_FALSE only if the item does not match, whether or not it 
        contains the GIN_MAYBE keys. If the result depends on the GIN_MAYBE
-       entries, ie. the match cannot be confirmed or refuted based on the
+       entries, i.e. the match cannot be confirmed or refuted based on the
        known query keys, the function must return GIN_MAYBE.
       </para>
       <para>
diff --git a/src/backend/access/gin/ginget.c b/src/backend/access/gin/ginget.c
index e24ff18..9d96bf5 100644
--- a/src/backend/access/gin/ginget.c
+++ b/src/backend/access/gin/ginget.c
@@ -933,7 +933,7 @@ keyGetItem(GinState *ginstate, MemoryContext tempCtx, GinScanKey key,
 	/*
 	 * Ok, we now know that there are no matches < minItem.
 	 *
-	 * If minItem is lossy, it means that there there were no exact items on
+	 * If minItem is lossy, it means that there were no exact items on
 	 * the page among requiredEntries, because lossy pointers sort after exact
 	 * items. However, there might be exact items for the same page among
 	 * additionalEntries, so we mustn't advance past them.
diff --git a/src/backend/access/gin/ginlogic.c b/src/backend/access/gin/ginlogic.c
index 4c8d706..b13ce4c 100644
--- a/src/backend/access/gin/ginlogic.c
+++ b/src/backend/access/gin/ginlogic.c
@@ -10,7 +10,7 @@
  * a GIN scan can apply various optimizations, if it can determine that an
  * item matches or doesn't match, even if it doesn't know if some of the keys
  * are present or not. Hence, it's useful to have a ternary-logic consistent
- * function, where where each key can be TRUE (present), FALSE (not present),
+ * function, where each key can be TRUE (present), FALSE (not present),
  * or MAYBE (don't know if present). This file provides such a ternary-logic
  * consistent function,  implemented by calling the regular boolean consistent
  * function many times, with all the MAYBE arguments set to all combinations
diff --git a/src/backend/access/heap/rewriteheap.c b/src/backend/access/heap/rewriteheap.c
index 239c7da..4cf07ea 100644
--- a/src/backend/access/heap/rewriteheap.c
+++ b/src/backend/access/heap/rewriteheap.c
@@ -783,9 +783,9 @@ raw_heap_insert(RewriteState state, HeapTuple tup)
  * deal with WAL logging at all - an fsync() at the end of a rewrite would be
  * sufficient for crash safety. Any mapping that hasn't been safely flushed to
  * disk has to be by an aborted (explicitly or via a crash) transaction and is
- * ignored by virtue of the xid in it's name being subject to a
+ * ignored by virtue of the xid in its name being subject to a
  * TransactionDidCommit() check. But we want to support having standbys via
- * physical replication, both for availability and to to do logical decoding
+ * physical replication, both for availability and to do logical decoding
  * there.
  * ------------------------------------------------------------------------
  */
@@ -1046,7 +1046,7 @@ logical_rewrite_log_mapping(RewriteState state, TransactionId xid,
 
 /*
  * Perform logical remapping for a tuple that's mapped from old_tid to
- * new_tuple->t_self by rewrite_heap_tuple() iff necessary for the tuple.
+ * new_tuple->t_self by rewrite_heap_tuple() if necessary for the tuple.
  */
 static void
 logical_rewrite_heap_tuple(RewriteState state, ItemPointerData old_tid,
diff --git a/src/backend/lib/ilist.c b/src/backend/lib/ilist.c
index 58c5810..73a6473 100644
--- a/src/backend/lib/ilist.c
+++ b/src/backend/lib/ilist.c
@@ -26,7 +26,7 @@
 /*
  * Delete 'node' from list.
  *
- * It is not allowed to delete a 'node' which is is not in the list 'head'
+ * It is not allowed to delete a 'node' which is not in the list 'head'
  *
  * Caution: this is O(n); consider using slist_delete_current() instead.
  */
diff --git a/src/backend/replication/logical/logical.c b/src/backend/replication/logical/logical.c
index 04e407a..8c6c6c2 100644
--- a/src/backend/replication/logical/logical.c
+++ b/src/backend/replication/logical/logical.c
@@ -293,7 +293,7 @@ CreateInitDecodingContext(char *plugin,
 	 * So we have to acquire the ProcArrayLock to prevent computation of new
 	 * xmin horizons by other backends, get the safe decoding xid, and inform
 	 * the slot machinery about the new limit. Once that's done the
-	 * ProcArrayLock can be be released as the slot machinery now is
+	 * ProcArrayLock can be released as the slot machinery now is
 	 * protecting against vacuum.
 	 * ----
 	 */
diff --git a/src/backend/replication/logical/snapbuild.c b/src/backend/replication/logical/snapbuild.c
index 28f9a8a..e74053c 100644
--- a/src/backend/replication/logical/snapbuild.c
+++ b/src/backend/replication/logical/snapbuild.c
@@ -55,7 +55,7 @@
  *
  *
  *
- * The snapbuild machinery is starting up in in several stages, as illustrated
+ * The snapbuild machinery is starting up in several stages, as illustrated
  * by the following graph:
  *         +-------------------------+
  *    +----|SNAPBUILD_START          |-------------+
@@ -779,7 +779,7 @@ SnapBuildDistributeNewCatalogSnapshot(SnapBuild *builder, XLogRecPtr lsn)
 		/*
 		 * If we don't have a base snapshot yet, there are no changes in this
 		 * transaction which in turn implies we don't yet need a snapshot at
-		 * all. We'll add add a snapshot when the first change gets queued.
+		 * all. We'll add a snapshot when the first change gets queued.
 		 *
 		 * NB: This works correctly even for subtransactions because
 		 * ReorderBufferCommitChild() takes care to pass the parent the base
diff --git a/src/backend/rewrite/rewriteHandler.c b/src/backend/rewrite/rewriteHandler.c
index f4f49d2..3728d8c 100644
--- a/src/backend/rewrite/rewriteHandler.c
+++ b/src/backend/rewrite/rewriteHandler.c
@@ -2343,7 +2343,7 @@ relation_is_updatable(Oid reloid,
 
 			/*
 			 * Determine which of the view's columns are updatable. If there
-			 * are none within the set of of columns we are looking at, then
+			 * are none within the set of columns we are looking at, then
 			 * the view doesn't support INSERT/UPDATE, but it may still
 			 * support DELETE.
 			 */
diff --git a/src/backend/utils/adt/json.c b/src/backend/utils/adt/json.c
index f170661..97a0e9f 100644
--- a/src/backend/utils/adt/json.c
+++ b/src/backend/utils/adt/json.c
@@ -395,7 +395,7 @@ parse_object(JsonLexContext *lex, JsonSemAction *sem)
 		(*ostart) (sem->semstate);
 
 	/*
-	 * Data inside an object at at a higher nesting level than the object
+	 * Data inside an object is at a higher nesting level than the object
 	 * itself. Note that we increment this after we call the semantic routine
 	 * for the object start and restore it before we call the routine for the
 	 * object end.
@@ -473,7 +473,7 @@ parse_array(JsonLexContext *lex, JsonSemAction *sem)
 		(*astart) (sem->semstate);
 
 	/*
-	 * Data inside an array at at a higher nesting level than the array
+	 * Data inside an array is at a higher nesting level than the array
 	 * itself. Note that we increment this after we call the semantic routine
 	 * for the array start and restore it before we call the routine for the
 	 * array end.
diff --git a/src/backend/utils/time/tqual.c b/src/backend/utils/time/tqual.c
index c4732ed..89f5ff8 100644
--- a/src/backend/utils/time/tqual.c
+++ b/src/backend/utils/time/tqual.c
@@ -1549,7 +1549,7 @@ HeapTupleHeaderIsOnlyLocked(HeapTupleHeader tuple)
 }
 
 /*
- * check whether the transaciont id 'xid' in in the pre-sorted array 'xip'.
+ * check whether the transaciont id 'xid' is in the pre-sorted array 'xip'.
  */
 static bool
 TransactionIdInArray(TransactionId xid, TransactionId *xip, Size num)
@@ -1589,7 +1589,7 @@ HeapTupleSatisfiesHistoricMVCC(HeapTuple htup, Snapshot snapshot,
 		Assert(!TransactionIdDidCommit(xmin));
 		return false;
 	}
-	/* check if its one of our txids, toplevel is also in there */
+	/* check if it's one of our txids, toplevel is also in there */
 	else if (TransactionIdInArray(xmin, snapshot->subxip, snapshot->subxcnt))
 	{
 		bool		resolved;
@@ -1598,7 +1598,7 @@ HeapTupleSatisfiesHistoricMVCC(HeapTuple htup, Snapshot snapshot,
 
 		/*
 		 * another transaction might have (tried to) delete this tuple or
-		 * cmin/cmax was stored in a combocid. S we need to to lookup the
+		 * cmin/cmax was stored in a combocid. So we need to lookup the
 		 * actual values externally.
 		 */
 		resolved = ResolveCminCmaxDuringDecoding(HistoricSnapshotGetTupleCids(), snapshot,
@@ -1662,7 +1662,7 @@ HeapTupleSatisfiesHistoricMVCC(HeapTuple htup, Snapshot snapshot,
 		xmax = HeapTupleGetUpdateXid(tuple);
 	}
 
-	/* check if its one of our txids, toplevel is also in there */
+	/* check if it's one of our txids, toplevel is also in there */
 	if (TransactionIdInArray(xmax, snapshot->subxip, snapshot->subxcnt))
 	{
 		bool resolved;
-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to