From 150a9df5288d2ba59a26767659a99c44b683fe8f Mon Sep 17 00:00:00 2001 From: Heikki Linnakangas Date: Thu, 10 Apr 2014 00:53:15 +0300 Subject: [PATCH] Fix a few more misc typos in comments. --- src/backend/replication/logical/snapbuild.c | 12 ++++++------ src/include/access/htup.h | 2 +- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/src/backend/replication/logical/snapbuild.c b/src/backend/replication/logical/snapbuild.c index 6a8b194c1bc..c462e9059d6 100644 --- 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 bfe5653fa44..178f6dc4a8a 100644 --- 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;