Fix markup

QUICKSTART.md

@@ -1,7 +1,7 @@
 repmgr: Quickstart guide
 ========================
 
-repmgr is an open-source tool suite for mananaging replication and failover
+`repmgr` is an open-source tool suite for mananaging replication and failover
 among multiple PostgreSQL server nodes. It enhances PostgreSQL's built-in
 hot-standby capabilities with a set of administration tools for monitoring
 replication, setting up standby servers and performing failover/switchover
@@ -14,14 +14,14 @@ covering setup on a variety of different systems, see the README.rst file.
 Conceptual Overview
 -------------------
 
-repmgr provides two binaries:
+`repmgr` provides two binaries:
 
- - `repmgr`: a command-line client to manage replication and repmgr configuration
+ - `repmgr`: a command-line client to manage replication and `repmgr` configuration
  - `repmgrd`: an optional daemon process which runs on standby nodes to monitor
    replication and node status
 
-Each PostgreSQL node requires a repmgr configuration file; additionally
+Each PostgreSQL node requires a `repmgr` configuration file; additionally
-it must be "registered" using the repmgr command-line client. repmgr stores
+it must be "registered" using the `repmgr` command-line client. `repmgr` stores
 information about managed nodes in a custom schema on the node's current master
 database.
 
@@ -29,31 +29,31 @@ database.
 Requirements
 ------------
 
-repmgr works with PostgreSQL 9.0 and later. All server nodes must be running the
+`repmgr` works with PostgreSQL 9.0 and later. All server nodes must be running the
 same PostgreSQL major version, and preferably should be running the same minor
 version.
 
-repmgr will work on any Linux or UNIX-like environment capable of running
+`repmgr` will work on any Linux or UNIX-like environment capable of running
 PostgreSQL. `rsync` must also be installed.
 
 
 Installation
 ------------
 
-repmgr must be installed on each PostgreSQL server node.
+`repmgr` must be installed on each PostgreSQL server node.
 
 * Packages
  - RPM packages for RedHat-based distributions are available from PGDG
  - Debian/Ubuntu provide .deb packages.
 
-  It is also possible to build .deb packages directly from the repmgr source;
+  It is also possible to build .deb packages directly from the `repmgr` source;
   see README.rst for further details.
 
 * Source installation
- - repmgr source code is hosted at github (https://github.com/2ndQuadrant/repmgr);
+ - `repmgr` source code is hosted at github (https://github.com/2ndQuadrant/`repmgr`);
-   tar.gz files can be downloaded from https://github.com/2ndQuadrant/repmgr/releases .
+   tar.gz files can be downloaded from https://github.com/2ndQuadrant/`repmgr`/releases .
 
-   repmgr can be built easily using PGXS:
+   `repmgr` can be built easily using PGXS:
 
        sudo make USE_PGXS=1 install
 
@@ -64,7 +64,7 @@ Configuration
 ### Server configuration
 
 Password-less SSH logins must be enabled for the database system user (typically `postgres`)
-between all server nodes to enable repmgr to copy required files.
+between all server nodes to enable `repmgr` to copy required files.
 
 ### PostgreSQL configuration
 
@@ -78,21 +78,21 @@ following settings:
     wal_keep_segments = 5000       # in logfile segments, 16MB each; 0 disables
     hot_standby = on               # "on" allows queries during recovery
 
-Note that repmgr expects a default of 5000 wal_keep_segments, although this
+Note that `repmgr` expects a default of 5000 wal_keep_segments, although this
 value can be overridden when executing the `repmgr` client.
 
-Additionally, repmgr requires a dedicated PostgreSQL superuser account
+Additionally, `repmgr` requires a dedicated PostgreSQL superuser account
-and a database in which to store monitoring and replication data. The repmgr
+and a database in which to store monitoring and replication data. The `repmgr`
 user account will also be used for replication connections from the standby,
 so a seperate replication user with the `REPLICATION` privilege is not required.
 The database can in principle be any database, including the default `postgres`
-one, however it's probably advisable to create a dedicated database for repmgr
+one, however it's probably advisable to create a dedicated database for `repmgr`
 usage.
 
 
 ### repmgr configuration
 
-Each PostgreSQL node requires a repmgr configuration file containing
+Each PostgreSQL node requires a `repmgr` configuration file containing
 identification and database connection information:
 
     cluster=test
@@ -113,9 +113,9 @@ identification and database connection information:
 Note that the configuration file should *not* be stored inside the PostgreSQL
 data directory.
 
-Each node configuration needs to be registered with repmgr, either using the
+Each node configuration needs to be registered with `repmgr`, either using the
 `repmgr` command line tool, or the `repmgrd` daemon; for details see below. Details
-about each node are inserted into the repmgr database (for details see below).
+about each node are inserted into the `repmgr` database (for details see below).
 
 
 Replication setup and monitoring
@@ -141,9 +141,9 @@ Master setup
 	CREATE DATABASE repmgr_db OWNER repmgr_usr;
 	```
 
-  - configure postgresql.conf for replication (see above)
+  - configure `postgresql.conf` for replication (see above)
 
-  - update pg_hba.conf, e.g.:
+  - update `pg_hba.conf`, e.g.:
 
 	```
 	host    repmgr_db       repmgr_usr  192.168.1.0/24         trust
@@ -151,7 +151,7 @@ Master setup
 	```
 
   Restart the PostgreSQL server after making these changes.
-2. Create the repmgr configuration file:
+2. Create the `repmgr` configuration file:
 
         $ cat $HOME/repmgr/repmgr.conf
         cluster=test
@@ -160,7 +160,7 @@ Master setup
         conninfo='host=repmgr_node1 user=repmgr_usr dbname=repmgr_db'
         pg_bindir=/path/to/postgres/bin
 
-3. Register the master node with repmgr:
+3. Register the master node with `repmgr`:
 
         $ repmgr -f $HOME/repmgr/repmgr.conf --verbose master register
         [2014-07-04 10:43:42] [INFO] repmgr mgr connecting to master database
@@ -172,7 +172,7 @@ Master setup
 Slave/standby setup
 -------------------
 
-1. Use repmgr to clone the master:
+1. Use `repmgr` to clone the master:
 
         $ repmgr -D $PGDATA -d repmgr_db -U repmgr_usr -R postgres --verbose standby clone 192.168.1.2
         Opening configuration file: ./repmgr.conf
@@ -200,7 +200,7 @@ Slave/standby setup
 
 2. Start the PostgreSQL server
 
-3. Create the repmgr configuration file:
+3. Create the `repmgr` configuration file:
 
         $ cat $HOME/repmgr/repmgr.conf
         cluster=test
@@ -209,7 +209,7 @@ Slave/standby setup
         conninfo='host=repmgr_node2 user=repmgr_usr dbname=repmgr_db'
         pg_bindir=/path/to/postgres/bin
 
-4. Register the master node with repmgr:
+4. Register the master node with `repmgr`:
 
         $ repmgr -f $HOME/repmgr/repmgr.conf --verbose standby register
         Opening configuration file: /path/to/repmgr/repmgr.conf
@@ -258,8 +258,8 @@ To promote a standby to master, on the standby execute e.g.:
 
     repmgr -f  $HOME/repmgr/repmgr.conf --verbose standby promote
 
-repmgr will attempt to connect to the current master to verify that it
+`repmgr` will attempt to connect to the current master to verify that it
-is not available (if it is, repmgr will not promote the standby).
+is not available (if it is, `repmgr` will not promote the standby).
 
 Other standby servers need to be told to follow the new master with:
 
@@ -272,7 +272,7 @@ automated failover.
 repmgr database schema
 ----------------------
 
-repmgr creates a small schema for its own use in the database specified in
+`repmgr` creates a small schema for its own use in the database specified in
 each node's conninfo configuration parameter. This database can in principle
 be any database. The schema name is the global `cluster` name prefixed
 with `repmgr_`, so for the example setup above the schema name is