Adjust spellings of forms of "cancel"

Author: petere

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

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.
  *

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

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.
 		 */

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)))