|
93 | 93 | * Initially the machinery is in the START stage. When an xl_running_xacts |
94 | 94 | * record is read that is sufficiently new (above the safe xmin horizon), |
95 | 95 | * there's a state transition. If there were no running xacts when the |
96 | | - *running_xacts record was generated, we'll directly go into CONSISTENT |
| 96 | + *xl_running_xacts record was generated, we'll directly go into CONSISTENT |
97 | 97 | * state, otherwise we'll switch to the BUILDING_SNAPSHOT state. Having a full |
98 | 98 | * snapshot means that all transactions that start henceforth can be decoded |
99 | 99 | * in their entirety, but transactions that started previously can't. In |
@@ -1331,7 +1331,7 @@ SnapBuildFindSnapshot(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *runn |
1331 | 1331 | */ |
1332 | 1332 |
|
1333 | 1333 | /* |
1334 | | - *xl_running_xact record is older than what we can use, we might not have |
| 1334 | + *xl_running_xacts record is older than what we can use, we might not have |
1335 | 1335 | * all necessary catalog rows anymore. |
1336 | 1336 | */ |
1337 | 1337 | if (TransactionIdIsNormal(builder->initial_xmin_horizon)&& |
@@ -1399,7 +1399,7 @@ SnapBuildFindSnapshot(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *runn |
1399 | 1399 | * encountered. In that case, switch to BUILDING_SNAPSHOT state, and |
1400 | 1400 | * record xl_running_xacts->nextXid. Once all running xacts have finished |
1401 | 1401 | * (i.e. they're all >= nextXid), we have a complete catalog snapshot. It |
1402 | | - * might look that we could usexl_running_xact's ->xids information to |
| 1402 | + * might look that we could usexl_running_xacts's ->xids information to |
1403 | 1403 | * get there quicker, but that is problematic because transactions marked |
1404 | 1404 | * as running, might already have inserted their commit record - it's |
1405 | 1405 | * infeasible to change that with locking. |
|