Fix a few more misc typos in comments.

diff --git a/src/backend/replication/logical/snapbuild.c b/src/backend/replication/logical/snapbuild.c
index 6a8b194c1bcb1b322a3bdce896bd91a1653cc074..c462e9059d64018db90a37c32f36da521d2feb48 100644 (file)
--- a/src/backend/replication/logical/snapbuild.c
+++ b/src/backend/replication/logical/snapbuild.c
@@ -29,7 +29,7 @@
  * As the percentage of transactions modifying the catalog normally is fairly
  * small in comparisons to ones only manipulating user data, we keep track of
  * the committed catalog modifying ones inside (xmin, xmax) instead of keeping
- * track of all running transactions like its done in a normal snapshot. Note
+ * track of all running transactions like it's done in a normal snapshot. Note
  * that we're generally only looking at transactions that have acquired an
  * xid. That is we keep a list of transactions between snapshot->(xmin, xmax)
  * that we consider committed, everything else is considered aborted/in
@@ -81,7 +81,7 @@
  *
  * Initially the machinery is in the START stage. When a xl_running_xacts
  * record is read that is sufficiently new (above the safe xmin horizon),
- * there's a state transation. If there were no running xacts when the
+ * there's a state transition. If there were no running xacts when the
  * runnign_xacts record was generated, we'll directly go into CONSISTENT
  * state, otherwise we'll switch to the FULL_SNAPSHOT state. Having a full
  * snapshot means that all transactions that start henceforth can be decoded
@@ -412,7 +412,7 @@ SnapBuildSnapDecRefcount(Snapshot snap)
 
    Assert(snap->active_count);
 
-   /* slightly more likely, so its checked even without casserts */
+   /* slightly more likely, so it's checked even without casserts */
    if (snap->copied)
        elog(ERROR, "cannot free a copied snapshot");
 
@@ -451,7 +451,7 @@ SnapBuildBuildSnapshot(SnapBuild *builder, TransactionId xid)
     *
     * In the 'xip' array we store transactions that have to be treated as
     * committed. Since we will only ever look at tuples from transactions
-    * that have modified the catalog its more efficient to store those few
+    * that have modified the catalog it's more efficient to store those few
     * that exist between xmin and xmax (frequently there are none).
     *
     * Snapshots that are used in transactions that have modified the catalog
@@ -1117,7 +1117,7 @@ SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn, xl_running_xact
        SnapBuildSerialize(builder, lsn);
 
    /*
-    * Update range of interesting xids base don the running xacts
+    * Update range of interesting xids based on the running xacts
     * information. We don't increase ->xmax using it, because once we are in
     * a consistent state we can do that ourselves and much more efficiently
     * so, because we only need to do it for catalog transactions since we
@@ -1125,7 +1125,7 @@ SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn, xl_running_xact
     *
     * NB: Because of that xmax can be lower than xmin, because we only
     * increase xmax when a catalog modifying transaction commits. While odd
-    * looking, its correct and actually more efficient this way since we hit
+    * looking, it's correct and actually more efficient this way since we hit
     * fast paths in tqual.c.
     */
    builder->xmin = running->oldestRunningXid;

diff --git a/src/include/access/htup.h b/src/include/access/htup.h
index bfe5653fa44b6144404938f631b1abd4d3a3c69a..178f6dc4a8ae3b4b156e4587056b8cd57c3ff4ee 100644 (file)
--- a/src/include/access/htup.h
+++ b/src/include/access/htup.h
@@ -16,7 +16,7 @@
 
 #include "storage/itemptr.h"
 
-/* typedefs and forward declarations for structs defined in htup.h */
+/* typedefs and forward declarations for structs defined in htup_details.h */
 
 typedef struct HeapTupleHeaderData HeapTupleHeaderData;