|
29 | 29 | * As the percentage of transactions modifying the catalog normally is fairly |
30 | 30 | * small in comparisons to ones only manipulating user data, we keep track of |
31 | 31 | * the committed catalog modifying ones inside (xmin, xmax) instead of keeping |
32 | | - * track of all running transactions likeits done in a normal snapshot. Note |
| 32 | + * track of all running transactions likeit's done in a normal snapshot. Note |
33 | 33 | * that we're generally only looking at transactions that have acquired an |
34 | 34 | * xid. That is we keep a list of transactions between snapshot->(xmin, xmax) |
35 | 35 | * that we consider committed, everything else is considered aborted/in |
|
81 | 81 | * |
82 | 82 | * Initially the machinery is in the START stage. When a xl_running_xacts |
83 | 83 | * record is read that is sufficiently new (above the safe xmin horizon), |
84 | | - * there's a statetransation. If there were no running xacts when the |
| 84 | + * there's a statetransition. If there were no running xacts when the |
85 | 85 | * runnign_xacts record was generated, we'll directly go into CONSISTENT |
86 | 86 | * state, otherwise we'll switch to the FULL_SNAPSHOT state. Having a full |
87 | 87 | * snapshot means that all transactions that start henceforth can be decoded |
@@ -412,7 +412,7 @@ SnapBuildSnapDecRefcount(Snapshot snap) |
412 | 412 |
|
413 | 413 | Assert(snap->active_count); |
414 | 414 |
|
415 | | -/* slightly more likely, soits checked even without casserts */ |
| 415 | +/* slightly more likely, soit's checked even without casserts */ |
416 | 416 | if (snap->copied) |
417 | 417 | elog(ERROR,"cannot free a copied snapshot"); |
418 | 418 |
|
@@ -451,7 +451,7 @@ SnapBuildBuildSnapshot(SnapBuild *builder, TransactionId xid) |
451 | 451 | * |
452 | 452 | * In the 'xip' array we store transactions that have to be treated as |
453 | 453 | * committed. Since we will only ever look at tuples from transactions |
454 | | - * that have modified the catalogits more efficient to store those few |
| 454 | + * that have modified the catalogit's more efficient to store those few |
455 | 455 | * that exist between xmin and xmax (frequently there are none). |
456 | 456 | * |
457 | 457 | * Snapshots that are used in transactions that have modified the catalog |
@@ -1117,15 +1117,15 @@ SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn, xl_running_xact |
1117 | 1117 | SnapBuildSerialize(builder,lsn); |
1118 | 1118 |
|
1119 | 1119 | /* |
1120 | | - * Update range of interesting xidsbase don the running xacts |
| 1120 | + * Update range of interesting xidsbased on the running xacts |
1121 | 1121 | * information. We don't increase ->xmax using it, because once we are in |
1122 | 1122 | * a consistent state we can do that ourselves and much more efficiently |
1123 | 1123 | * so, because we only need to do it for catalog transactions since we |
1124 | 1124 | * only ever look at those. |
1125 | 1125 | * |
1126 | 1126 | * NB: Because of that xmax can be lower than xmin, because we only |
1127 | 1127 | * 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 |
1129 | 1129 | * fast paths in tqual.c. |
1130 | 1130 | */ |
1131 | 1131 | builder->xmin=running->oldestRunningXid; |
|