Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 150a9df

Browse files
committed
Fix a few more misc typos in comments.
1 parent 85c6bba commit 150a9df

File tree

2 files changed

+7
-7
lines changed

2 files changed

+7
-7
lines changed

src/backend/replication/logical/snapbuild.c

+6-6
Original file line numberDiff line numberDiff line change
@@ -29,7 +29,7 @@
2929
* As the percentage of transactions modifying the catalog normally is fairly
3030
* small in comparisons to ones only manipulating user data, we keep track of
3131
* the committed catalog modifying ones inside (xmin, xmax) instead of keeping
32-
* track of all running transactions like its done in a normal snapshot. Note
32+
* track of all running transactions like it's done in a normal snapshot. Note
3333
* that we're generally only looking at transactions that have acquired an
3434
* xid. That is we keep a list of transactions between snapshot->(xmin, xmax)
3535
* that we consider committed, everything else is considered aborted/in
@@ -81,7 +81,7 @@
8181
*
8282
* Initially the machinery is in the START stage. When a xl_running_xacts
8383
* record is read that is sufficiently new (above the safe xmin horizon),
84-
* there's a state transation. If there were no running xacts when the
84+
* there's a state transition. If there were no running xacts when the
8585
* runnign_xacts record was generated, we'll directly go into CONSISTENT
8686
* state, otherwise we'll switch to the FULL_SNAPSHOT state. Having a full
8787
* snapshot means that all transactions that start henceforth can be decoded
@@ -412,7 +412,7 @@ SnapBuildSnapDecRefcount(Snapshot snap)
412412

413413
Assert(snap->active_count);
414414

415-
/* slightly more likely, so its checked even without casserts */
415+
/* slightly more likely, so it's checked even without casserts */
416416
if (snap->copied)
417417
elog(ERROR, "cannot free a copied snapshot");
418418

@@ -451,7 +451,7 @@ SnapBuildBuildSnapshot(SnapBuild *builder, TransactionId xid)
451451
*
452452
* In the 'xip' array we store transactions that have to be treated as
453453
* committed. Since we will only ever look at tuples from transactions
454-
* that have modified the catalog its more efficient to store those few
454+
* that have modified the catalog it's more efficient to store those few
455455
* that exist between xmin and xmax (frequently there are none).
456456
*
457457
* Snapshots that are used in transactions that have modified the catalog
@@ -1117,15 +1117,15 @@ SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn, xl_running_xact
11171117
SnapBuildSerialize(builder, lsn);
11181118

11191119
/*
1120-
* Update range of interesting xids base don the running xacts
1120+
* Update range of interesting xids based on the running xacts
11211121
* information. We don't increase ->xmax using it, because once we are in
11221122
* a consistent state we can do that ourselves and much more efficiently
11231123
* so, because we only need to do it for catalog transactions since we
11241124
* only ever look at those.
11251125
*
11261126
* NB: Because of that xmax can be lower than xmin, because we only
11271127
* increase xmax when a catalog modifying transaction commits. While odd
1128-
* looking, its correct and actually more efficient this way since we hit
1128+
* looking, it's correct and actually more efficient this way since we hit
11291129
* fast paths in tqual.c.
11301130
*/
11311131
builder->xmin = running->oldestRunningXid;

src/include/access/htup.h

+1-1
Original file line numberDiff line numberDiff line change
@@ -16,7 +16,7 @@
1616

1717
#include "storage/itemptr.h"
1818

19-
/* typedefs and forward declarations for structs defined in htup.h */
19+
/* typedefs and forward declarations for structs defined in htup_details.h */
2020

2121
typedef struct HeapTupleHeaderData HeapTupleHeaderData;
2222

0 commit comments

Comments
 (0)