|
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 like its done in a normal snapshot. Note |
| 32 | + * track of all running transactions like it'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 state transation. If there were no running xacts when the |
| 84 | + * there's a state transition. 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, so its checked even without casserts */ |
| 415 | + /* slightly more likely, so it'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 catalog its more efficient to store those few |
| 454 | + * that have modified the catalog it'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 xids base don the running xacts |
| 1120 | + * Update range of interesting xids based 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;
|
|
0 commit comments