Merge pull request #2727 from citusdata/spellcheck

Fix misc typos (2)

src/backend/distributed/commands/README.md

@@ -2,8 +2,8 @@
 
 The commands module is modeled after `backend/commands` from the postgres repository and
 contains the logic for Citus on how to run these commands on distributed objects. Even
-though the structure of the directory has some resemblence to its postgres relative files
+though the structure of the directory has some resemblence to its postgres relative, files
-here are somewhat more finegrained. This is due to the nature of citus commands that are
+here are somewhat more fine-grained. This is due to the nature of citus commands that are
 heavily focused on distributed tables. Instead of having all commands in `tablecmds.c`
 they are often moved to files that are named after the command.
 
@@ -12,7 +12,7 @@ they are often moved to files that are named after the command.
 | `create_distributed_table.c` | Implementation of UDF's for creating distributed tables |
 | `drop_distributed_table.c`   | Implementation for dropping metadata for partitions of distributed tables |
 | `extension.c`                | Implementation of `CREATE EXTENSION` commands for citus specific checks |
-| `foreign_constraint.c`       | Implementation of and helper functions for foreign key constraints |
+| `foreign_constraint.c`       | Implementation of helper functions for foreign key constraints |
 | `grant.c`                    | Placeholder for code granting users access to relations, implemented as enterprise feature |
 | `index.c`                    | Implementation of commands specific to indices on distributed tables |
 | `multi_copy.c`               | Implementation of `COPY` command. There are multiple different copy modes which are described in detail below |

src/backend/distributed/commands/table.c

@@ -1090,7 +1090,7 @@ ErrorIfUnsupportedAlterTableStmt(AlterTableStmt *alterTableStatement)
 
 /*
  * SetupExecutionModeForAlterTable is the function that is responsible
- * for two things for practial purpose for not doing the same checks
+ * for two things for practical purpose for not doing the same checks
  * twice:
  *     (a) For any command, decide and return whether we should
  *         run the command in sequential mode

src/backend/distributed/planner/insert_select_planner.c

@@ -1127,7 +1127,7 @@ InsertPartitionColumnMatchesSelect(Query *query, RangeTblEntry *insertRte,
 
 
 /*
- * CreatteCoordinatorInsertSelectPlan creates a query plan for a SELECT into a
+ * CreateCoordinatorInsertSelectPlan creates a query plan for a SELECT into a
  * distributed table. The query plan can also be executed on a worker in MX.
  */
 static DistributedPlan *
@@ -1330,7 +1330,7 @@ WrapSubquery(Query *subquery)
 
 
 /*
- * TwoPhaseInsertSelectTaskList generates a list of task for a query that
+ * TwoPhaseInsertSelectTaskList generates a list of tasks for a query that
  * inserts into a target relation and selects from a set of co-located
  * intermediate results.
  */

src/backend/distributed/planner/query_colocation_checker.c

@@ -131,7 +131,7 @@ AnchorRte(Query *subquery)
 		RangeTblEntry *currentRte = rt_fetch(currentRTEIndex, subquery->rtable);
 
 		/*
-		 * We always prefer distributed releations if we can find any. The
+		 * We always prefer distributed relations if we can find any. The
 		 * reason is that Citus is currently able to recursively plan
 		 * subqueries, but not relations.
 		 *

src/backend/distributed/progress/multi_progress.c

@@ -135,7 +135,7 @@ ProgressMonitorList(uint64 commandTypeMagicNumber, List **attachedDSMSegments)
 	const int dsmHandleIndex = 1 + 1 + 3;
 
 	/*
-	 * Currently, Postgres' progress logging mechanism supports only the VACUUM,
+	 * Currently, Postgres' progress logging mechanism supports only the VACUUM
 	 * operations. Therefore, we identify ourselves as a VACUUM command but only fill
 	 * a couple of the available fields. Therefore the commands that use Citus' progress
 	 * monitoring API will appear in pg_stat_progress_vacuum output.

src/test/regress/mitmscripts/README.md

@@ -1,7 +1,7 @@
 Automated Failure testing
 =========================
 
-Automated Failure Testing works by inserting a network proxy (mitmproxy) between the Citus coordinator and one of the workers (connections to the other worker are left unchanged). The proxy is configurable, and sits on a fifo waiting for commands. When it receives a command over the fifo it reconfigures itself and sends back response. Regression tests which use automated failure testing communicate with mitmproxy by running special UDFs which talk to said fifo. The tests send commands such as "fail any connection which contain the string `COMMIT`" and then run SQL queries and assert that thecoordinator has reasonable behavior when the specified failures occur.
+Automated Failure Testing works by inserting a network proxy (mitmproxy) between the Citus coordinator and one of the workers (connections to the other worker are left unchanged). The proxy is configurable, and sits on a fifo waiting for commands. When it receives a command over the fifo it reconfigures itself and sends back response. Regression tests which use automated failure testing communicate with mitmproxy by running special UDFs which talk to said fifo. The tests send commands such as "fail any connection which contain the string `COMMIT`" and then run SQL queries and assert that the coordinator has reasonable behavior when the specified failures occur.
 
 **Table of Contents**