Small documentation and user-facing messaging tweaks (#947)

* Fix typos in documentation and user-facing messages

* docs: Remove unsupported version

The 'pg_autoctl status' command doesn't accept the --monitor option,
so remove from the documentation.

Author: danielgustafsson

docs/citus-quickstart.rst

@@ -9,7 +9,7 @@ failure in the coordinator and worker nodes and see how the system continues
 to function.
 
 This tutorial uses `docker-compose`__ in order to separate the architecture
-design from some of the implementation details. This allows reasonning at
+design from some of the implementation details. This allows reasoning at
 the architecture level within this tutorial, and better see which software
 component needs to be deployed and run on which node.
 
@@ -192,7 +192,7 @@ actual nodes.
 __ https://yaml101.com/anchors-and-aliases/
 
 Also this time we provision an application service (named "app") that sits
-in the backgound and allow us to later connect to our current primary
+in the background and allow us to later connect to our current primary
 coordinator. See :download:`Dockerfile.app <citus/Dockerfile.app>` for the
 complete definition of this service.
 
@@ -254,7 +254,7 @@ Our first Citus worker failover
 -------------------------------
 
 We see that in the ``citus_get_active_worker_nodes()`` output we have
-``worker1a``, ``worker2b``, and ``worker3a``. As mentionned before, that
+``worker1a``, ``worker2b``, and ``worker3a``. As mentioned before, that
 should have no impact on the operations of the Citus cluster when nodes are
 all dimensionned the same.
 

docs/ref/pg_autoctl_create_postgres.rst

@@ -246,7 +246,7 @@ The following options are available to ``pg_autoctl create postgres``:
   connections in the Postgres HBA rules.
 
   For instance, when the monitor resolves to ``192.168.0.1`` and your local
-  Postgres node uses an inferface with IP address
+  Postgres node uses an interface with IP address
   ``192.168.0.2/255.255.255.0`` to connect to the monitor, then the LAN CIDR
   is computed to be ``192.168.0.0/24``.
 

docs/ref/pg_autoctl_status.rst

@@ -24,9 +24,7 @@ Options
 --pgdata
 
   Location of the Postgres node being managed locally. Defaults to the
-  environment variable ``PGDATA``. Use ``--monitor`` to connect to a monitor
-  from anywhere, rather than the monitor URI used by a local Postgres node
-  managed with ``pg_autoctl``.
+  environment variable ``PGDATA``.
 
 --json
 
@@ -42,8 +40,7 @@ PGDATA
 
 PG_AUTOCTL_MONITOR
 
-  Postgres URI to connect to the monitor node, can be used instead of the
-  ``--monitor`` option.
+  Postgres URI to connect to the monitor node.
 
 XDG_CONFIG_HOME
 

docs/security.rst

@@ -327,7 +327,7 @@ has been used at creation time. That's because the ``host`` records match
 either SSL or non-SSL connection attempts in Postgres HBA file, so the
 pre-existing setup will continue to work. To enhance the SSL setup, you can
 manually edit the HBA files and change the existing lines from ``host`` to
-``hostssl`` to dissallow unencrypted connections at the server side.
+``hostssl`` to disallow unencrypted connections at the server side.
 
 In summary, to upgrade an existing pg_auto_failover setup to enable SSL:
 

docs/tutorial.rst

@@ -8,7 +8,7 @@ standby. Then we'll add a second standby node. We’ll simulate failure in the
 Postgres nodes and see how the system continues to function.
 
 This tutorial uses `docker-compose`__ in order to separate the architecture
-design from some of the implementation details. This allows reasonning at
+design from some of the implementation details. This allows reasoning at
 the architecture level within this tutorial, and better see which software
 component needs to be deployed and run on which node.
 
@@ -202,7 +202,7 @@ Next steps
 As mentioned in the first section of this tutorial, the way we use
 docker-compose here is not meant to be production ready. It's useful to
 understand and play with a distributed system such as Postgres multiple
-nodes sytem and failovers.
+nodes system and failovers.
 
 See the command :ref:`pg_autoctl_do_tmux_compose_session` for more details
 about how to run a docker-compose test environment with docker-compose,

src/bin/lib/README.md

@@ -23,7 +23,7 @@ We utilize the "ini.h" ini-file reader from https://github.com/mattiasgustavsson
 
 ## JSON
 
-The parson librairy at https://github.com/kgabis/parson is a single C file
+The parson library at https://github.com/kgabis/parson is a single C file
 and MIT licenced. It allows parsing from and serializing to JSON.
 
 ## pg

src/bin/pg_autoctl/README.md

@@ -36,7 +36,7 @@ The code is organized in the following way:
   - files with a names that start with `ini_` implement our higher level
     facilities to handle configuration written in the INI format.
 
-  - files with a names that starts with `pg` implement abstrations used to
+  - files with a names that starts with `pg` implement abstractions used to
     handle a Postgres service:
 
 	  - the `pgsql` module contains code to query the local Postgres

src/bin/pg_autoctl/cli_create_node.c

@@ -1476,7 +1476,7 @@ check_hostname(const char *hostname)
 
 		if (!fetchLocalCIDR(hostname, cidr, BUFSIZE))
 		{
-			log_warn("Failed to find adress \"%s\" in local network "
+			log_warn("Failed to find address \"%s\" in local network "
 					 "interfaces, automated pg_hba.conf setup might fail.",
 					 hostname);
 		}