diff options
| -rw-r--r-- | src/backend/optimizer/util/orclauses.c | 2 | ||||
| -rw-r--r-- | src/backend/storage/ipc/standby.c | 2 | ||||
| -rw-r--r-- | src/backend/utils/adt/misc.c | 2 | ||||
| -rw-r--r-- | src/backend/utils/adt/numeric.c | 2 | ||||
| -rw-r--r-- | src/backend/utils/time/tqual.c | 2 |
5 files changed, 5 insertions, 5 deletions
diff --git a/src/backend/optimizer/util/orclauses.c b/src/backend/optimizer/util/orclauses.c index ea831f5a823..13570f006ec 100644 --- a/src/backend/optimizer/util/orclauses.c +++ b/src/backend/optimizer/util/orclauses.c @@ -54,7 +54,7 @@ static void consider_new_or_clause(PlannerInfo *root, RelOptInfo *rel, * fault is not really in the transformation, but in clauselist_selectivity's * inability to recognize redundant conditions.) We can compensate for this * redundancy by changing the cached selectivity of the original OR clause, - * cancelling out the (valid) reduction in the estimated sizes of the base + * canceling out the (valid) reduction in the estimated sizes of the base * relations so that the estimated joinrel size remains the same. This is * a MAJOR HACK: it depends on the fact that clause selectivities are cached * and on the fact that the same RestrictInfo node will appear in every diff --git a/src/backend/storage/ipc/standby.c b/src/backend/storage/ipc/standby.c index 7a512b3f81d..547f1a88fe2 100644 --- a/src/backend/storage/ipc/standby.c +++ b/src/backend/storage/ipc/standby.c @@ -348,7 +348,7 @@ ResolveRecoveryConflictWithDatabase(Oid dbid) * We either resolve conflicts immediately or set a timeout to wake us at * the limit of our patience. * - * Resolve conflicts by cancelling to all backends holding a conflicting + * Resolve conflicts by canceling to all backends holding a conflicting * lock. As we are already queued to be granted the lock, no new lock * requests conflicting with ours will be granted in the meantime. * diff --git a/src/backend/utils/adt/misc.c b/src/backend/utils/adt/misc.c index 10133f21fac..5e705e93084 100644 --- a/src/backend/utils/adt/misc.c +++ b/src/backend/utils/adt/misc.c @@ -532,7 +532,7 @@ pg_sleep(PG_FUNCTION_ARGS) * By computing the intended stop time initially, we avoid accumulation of * extra delay across multiple sleeps. This also ensures we won't delay * less than the specified time when WaitLatch is terminated early by a - * non-query-cancelling signal such as SIGHUP. + * non-query-canceling signal such as SIGHUP. */ #ifdef HAVE_INT64_TIMESTAMP diff --git a/src/backend/utils/adt/numeric.c b/src/backend/utils/adt/numeric.c index f49e113e5e7..2fbdfe07582 100644 --- a/src/backend/utils/adt/numeric.c +++ b/src/backend/utils/adt/numeric.c @@ -7289,7 +7289,7 @@ div_var_fast(NumericVar *var1, NumericVar *var2, NumericVar *result, * But having said that: div[qi] can be more than INT_MAX/NBASE, as * noted above, which means that the product div[qi] * NBASE *can* * overflow. When that happens, adding it to div[qi + 1] will always - * cause a cancelling overflow so that the end result is correct. We + * cause a canceling overflow so that the end result is correct. We * could avoid the intermediate overflow by doing the multiplication * and addition in int64 arithmetic, but so far there appears no need. */ diff --git a/src/backend/utils/time/tqual.c b/src/backend/utils/time/tqual.c index a08dae10974..2960455d6e3 100644 --- a/src/backend/utils/time/tqual.c +++ b/src/backend/utils/time/tqual.c @@ -419,7 +419,7 @@ HeapTupleSatisfiesToast(HeapTuple htup, Snapshot snapshot, /* * An invalid Xmin can be left behind by a speculative insertion that - * is cancelled by super-deleting the tuple. We shouldn't see any of + * is canceled by super-deleting the tuple. We shouldn't see any of * those in TOAST tables, but better safe than sorry. */ else if (!TransactionIdIsValid(HeapTupleHeaderGetXmin(tuple))) |