Merge pull request #4908 from EnterpriseDB/docs/edits_to_efm_nongener…

…ated_install_topics

edits to non-generated install topics

product_docs/docs/efm/4/installing/install_details.mdx

@@ -6,7 +6,7 @@ redirects:
 
 
 
-Components are installed in the following locations, where `4.x` indicates a minor release:
+Components are installed in the following locations, where `4.x` indicates a minor release.
 
 | Component                         | Location                      |
 | --------------------------------- | ----------------------------- |

product_docs/docs/efm/4/installing/prerequisites.mdx

@@ -11,11 +11,11 @@ legacyRedirectsGenerated:
 
 <div id="prerequisites" class="registered_link"></div>
 
-Before configuring a Failover Manager cluster, you must satisfy the prerequisites described below.
+Before configuring a Failover Manager cluster, you must satisfy these prerequisites.
 
-## Install Java 1.8 (or later)
+## Install Java 1.8 or later
 
-Before using Failover Manager, you must first install Java (version 1.8 or later). Failover Manager is tested with OpenJDK, and we strongly recommend installing that version of Java. [Installation instructions for Java](https://openjdk.java.net/install/) are platform specific.
+Before using Failover Manager, you must first install Java version 1.8 or later. Failover Manager is tested with OpenJDK, and we strongly recommend installing that version of Java. [Installation instructions for Java](https://openjdk.java.net/install/) are platform specific.
 
 !!! Note
     There's a temporary issue with OpenJDK version 11 on RHEL and its derivatives. When starting Failover Manager, you might see an error like the following:
@@ -28,22 +28,22 @@ Before using Failover Manager, you must first install Java (version 1.8 or later
 
 You can receive notifications from Failover Manager as specified by a user-defined notification script, by email, or both.
 
--   If you are using email notifications, an SMTP server must be running on each node of the Failover Manager scenario.
--   If you provide a value in the `script.notification` property, you can leave the `user.email` field blank; an SMTP server is not required.
+-   If you're using email notifications, an SMTP server must be running on each node of the Failover Manager scenario.
+-   If you provide a value in the `script.notification` property, you can leave the `user.email` field blank. An SMTP server isn't required.
 
 If an event occurs, Failover Manager invokes the script (if provided) and can also send a notification email to any email addresses specified in the `user.email` parameter of the cluster properties file. For more information about using an SMTP server, see the [Red Hat deployment guide](https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/s1-email-mta.html).
 
 ## Configure streaming replication
 
 Failover Manager requires that PostgreSQL streaming replication be configured between the primary node and the standby nodes. Failover Manager doesn't support other types of replication.
 
-On database versions 11 (or prior), unless specified with the `-sourcenode` option, a `recovery.conf` file is copied from a random standby node to the stopped primary during switchover. Ensure that the paths in the `recovery.conf` file on your standby nodes are consistent before performing a switchover. For more information about the `-sourcenode` option, see [Promoting a Failover Manager node](../05_using_efm/#promote_node).
+On database versions 11 or earlier, unless specified with the `-sourcenode` option, a `recovery.conf` file is copied from a random standby node to the stopped primary during switchover. Ensure that the paths in the `recovery.conf` file on your standby nodes are consistent before performing a switchover. For more information about the `-sourcenode` option, see [Promoting a Failover Manager node](../05_using_efm/#promote_node).
 
 On database version 12 or later, the `primary_conninfo` and `restore_command` properties are copied from a random standby node to the stopped primary during switchover unless otherwise specified with the `-sourcenode` option.
 
 ## Modify pg_hba.conf
 
-You must modify `pg_hba.conf` on the primary and standby nodes, adding entries that allow communication between all of the nodes in the cluster. The following example shows entries you might make to the `pg_hba.conf` file on the primary node:
+You must modify `pg_hba.conf` on the primary and standby nodes, adding entries that allow communication between all of the nodes in the cluster. This example shows entries you might make to the `pg_hba.conf` file on the primary node:
 
 ```shell
 # access for itself
@@ -58,19 +58,19 @@ Where:
 
  `efm` specifies the name of a valid database user.
 
- `fmdb` specifies the name of a database to which the efm user may connect.
+ `fmdb` specifies the name of a database to which the efm user can connect.
 
-By default, the `pg_hba.conf` file resides in the `data` directory, under your Postgres installation. After modifying the `pg_hba.conf` file, you must reload the configuration file on each node for the changes to take effect. You can use the following command:
+By default, the `pg_hba.conf` file resides in the `data` directory under your Postgres installation. After modifying the `pg_hba.conf` file, for the changes to take effect, you must reload the configuration file on each node. You can use the following command:
 
  `# systemctl reload edb-as-<x>`
 
 Where `x` specifies the Postgres version.
 
-## Using Autostart for the Database Servers
+## Using autostart for the database servers
 
-If a primary node reboots, Failover Manager might detect the database is down on the primary node and promote a standby node to the role of primary. If this happens, the Failover Manager agent on the rebooted primary node doesn't get a chance to write the `recovery.conf` file, and the `recovery.conf` file prevents the database server from starting. If this happens, the rebooted primary node returns to the cluster as a second primary node.
+If a primary node restarts, Failover Manager might detect the database is down on the primary node and promote a standby node to the role of primary. If this happens, the Failover Manager agent on the restarted primary node doesn't get a chance to write the `recovery.conf` file, and the `recovery.conf` file prevents the database server from starting. In this case, the rebooted primary node returns to the cluster as a second primary node.
 
-To prevent this condition, ensure that the Failover Manager agent auto starts before the database server. The agent starts in idle mode and checks to see if there is already a primary in the cluster. If there is a primary node, the agent verifies that a `recovery.conf` or `standby.signal` file exists. If neither file exits, the agent creates the `recovery.conf` file.
+To prevent this condition, ensure that the Failover Manager agent auto starts before the database server. The agent starts in idle mode and checks to see if there's already a primary in the cluster. If there's a primary node, the agent verifies that a `recovery.conf` or `standby.signal` file exists. If neither file exits, the agent creates the `recovery.conf` file.
 
 ## Ensure communication through firewalls
 
@@ -96,9 +96,7 @@ The database user specified by the `db.user` property in the `efm.properties` fi
  `pg_wal_replay_pause()`
 
 
-If the `reconfigure.num.sync` or `reconfigure.sync.primary` property is set to `true`, then:
-
-- For database versions 10 and later, the db.user requires `pg_read_all_stats` privilege and permissions to run `pg_reload_conf()`.
+If the `reconfigure.num.sync` or `reconfigure.sync.primary` property is set to `true`, then, for database versions 10 and later, the db.user requires `pg_read_all_stats` privilege and permissions to run `pg_reload_conf()`.
 
 For detailed information about each of these functions, see the [PostgreSQL core documentation](https://www.postgresql.org/docs/current/index.html).