|
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 use xl_running_xact's ->xids information to |
| 1402 | + * might look that we could use xl_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.
|
|
0 commit comments