A bucket of typos.

by @a.lakhin

Author: arssher

Cluster.pm

@@ -438,7 +438,7 @@ sub is_data_identic()
 		}
 		elsif ($checksum ne $current_hash)
 		{
-			note("got different hashes: $checksum ang $current_hash");
+			note("got different hashes: $checksum and $current_hash");
 			return 0;
 		}
 	}

README_old.md

@@ -58,7 +58,7 @@ While `multimaster` replicates data on the logical level, DDL is replicated on t
 The current implementation of logical replication sends data to subscriber nodes only after the local commit. In case of a heavy-write transaction, you have to wait for transaction processing twice: on the local node and on all the other nodes (simultaneously). 
 
 * Isolation level.
-The `multimaster` extenstion currently supports only the _repeatable_ _read_ isolation level. This is stricter than the default _read_ _commited_ level, but also increases probability of serialization failure during commit. _Serializable_ level is not supported yet.
+The `multimaster` extension currently supports only the _repeatable_ _read_ isolation level. This is stricter than the default _read_ _commited_ level, but also increases probability of serialization failure during commit. _Serializable_ level is not supported yet.
 
 
 ## Compatibility 

doc/specs/MtmGenerations.tla

@@ -23,7 +23,7 @@ VARIABLES
          \* local clog of node n
   acks, \* tx -> number of PREPARE acks
   clog,  \* tx -> TRUE (commit) | FALSE (abort): global clog (paxos emulation)
-  gens   \* Sequence of all ever elected generations. Models possiblity of
+  gens   \* Sequence of all ever elected generations. Models possibility of
          \* learning newer gen existence at any moment.
 
 

doc/specs/commit.md

@@ -357,7 +357,7 @@ More or less same algorithm is implemented in [commit.tla] and can be checked in
 
 Notes:
 
-[1] Now we do not abort in this case but just wait on lock. However if that local transaction will be successfully prepared then it will definetly catch a global deadlock with tx waiting for it. So it may be a good idea to abort one of them earlier -- probably a later one, since it didn't yet used resources of walsender/walreceivers and that will be cheaper for whole system.
+[1] Now we do not abort in this case but just wait on lock. However if that local transaction will be successfully prepared then it will definitely catch a global deadlock with tx waiting for it. So it may be a good idea to abort one of them earlier -- probably a later one, since it didn't yet used resources of walsender/walreceivers and that will be cheaper for whole system.
 
 Bibliography:
 

doc/specs/generations2.md

@@ -691,7 +691,7 @@ generation whenever it is present in the clique and either
    present in current_gen. i.e. we should exclude someone to proceed.
 
 How to recover initially, to decrease the lag without forcing nodes to wait for
-us? The idea is to collect with heartbeats also last_online_in of neightbours.
+us? The idea is to collect with heartbeats also last_online_in of neighbours.
 And node always before initiaing voting for adding itself would either make sure
 it most probably (unless many events pass during voting period) won't need
 recovery at all (its last_online_in is the same as clique's max) or it first

multimaster--1.0.sql

@@ -456,7 +456,7 @@ DECLARE
     altered boolean := false;
     saved_remotes text;
 BEGIN
-    -- with sparce node_id's max(node_id) can be bigger then n_nodes
+    -- with sparse node_id's max(node_id) can be bigger then n_nodes
     select max(id) into max_nodes from mtm.nodes();
     select current_setting('multimaster.remote_functions') into saved_remotes;
     set multimaster.remote_functions to 'mtm.alter_sequences';
@@ -485,7 +485,7 @@ BEGIN
     END LOOP;
     EXECUTE 'set multimaster.remote_functions to ''' || saved_remotes || '''';
     IF altered = false THEN
-        RAISE NOTICE 'All found sequnces have proper params.';
+        RAISE NOTICE 'All found sequences have proper params.';
     END IF;
     RETURN true;
 END

src/bgwpool.c

@@ -527,7 +527,7 @@ BgwPoolShutdown(BgwPool *poolDesc)
 /*
  * Hard termination of workers on some WAL receiver error.
  *
- * On error WAL receiver woll begin new iteration. But workers need to be killed
+ * On error WAL receiver will begin new iteration. But workers need to be killed
  * without finish of processing.
  * The queue will kept in memory, but its state will reset.
  */

src/commit.c

@@ -248,7 +248,7 @@ MtmBeginTransaction()
 	{
 		/*
 		 * Reject all user's transactions at offline cluster. Allow execution
-		 * of transaction by bg-workers to makeit possible to perform
+		 * of transaction by bg-workers to make it possible to perform
 		 * recovery.
 		 */
 		if (!MtmBreakConnection)

src/ddd.c

@@ -39,7 +39,7 @@
  *
  *    Situation when a transaction (say T1) in apply_worker (or receiver
  * itself) stucks on some lock created by a transaction in a local backend (say
- * T2) will definetly lead to a deadlock since T2 after beeing prepared and
+ * T2) will definitely lead to a deadlock since T2 after being prepared and
  * replicated will fail to obtain lock that is already held by T1.
  *    Same reasoning may be applied to the situation when apply_worker (or
  * receiver) is waiting for an apply_worker (or receiver) belonging to other
@@ -48,12 +48,12 @@
  *    Only case for distributed deadlock that is left is when apply_worker
  * (or receiver) is waiting for another apply_worker from same origin. However,
  * such situation isn't possible since one origin node can not have two
- * conflicting prepared transaction simultaneosly.
+ * conflicting prepared transaction simultaneously.
  *
  *    So we may construct distributed deadlock avoiding mechanism by disallowing
  * such edges. Now we may ask inverse question: what amount of wait graphs
  * with such edges are actually do not represent distributed deadlock? That may
- * happen in cases when holding transaction is purely local since it holdind
+ * happen in cases when holding transaction is purely local since it holding
  * locks only in SHARED mode. Only lock levels that are conflicting with this
  * modes are EXCLUSIVE and ACCESS EXCLUSIVE. In all other cases proposed
  * avoiding scheme should not yield false positives.
@@ -62,7 +62,7 @@
  * may throw exception not in WaitOnLock() when we first saw forbidden edge
  * but later during first call to local deadlock detector. This way we still
  * have `deadlock_timeout` second to grab that lock and database user also can
- * increse it on per-transaction basis if there are long-living read-only
+ * increase it on per-transaction basis if there are long-living read-only
  * transactions.
  *
  *     As a further optimization it is possible to check whether our lock is

src/ddl.c

@@ -810,7 +810,7 @@ MtmProcessUtilityReceiver(PlannedStmt *pstmt, const char *queryString,
 					break;
 				}
 
-				/* disable functiob body check at replica */
+				/* disable function body check at replica */
 			case T_CreateFunctionStmt:
 				check_function_bodies = false;
 				break;