diff --git a/doc/src/sgml/architecture.sgml b/doc/src/sgml/architecture.sgml
index b7589f9a4f..4bbd6abb8a 100644
--- a/doc/src/sgml/architecture.sgml
+++ b/doc/src/sgml/architecture.sgml
@@ -6,8 +6,11 @@
   <para>
    Every DBMS implements basic strategies to ensure a fast
    and robust system. This chapter provides an overview of the
-   techniques <productname>PostgreSQL</productname> uses to
-   achieve this.
+   basic techniques <productname>PostgreSQL</productname> uses to
+   achieve this aim. It does not offer anything which exceeds
+   the information content of other pages. Instead, it tries to
+   explain <emphasis>why</emphasis> certain implementation
+   decisions have been taken.
   </para>
 
   <sect1 id="tutorial-ram-proc-file">
@@ -28,10 +31,11 @@
    </para>
 
    <para>
-    The first step when an Instance starts is the start of the
+    All aspects of an Instance are launched and managed using a single primary
+    process termed the
     <glossterm linkend="glossary-postmaster">Postmaster</glossterm>.
-    It loads the configuration files, allocates Shared Memory, and
-    starts the other processes of the Instance:
+    It loads configuration files, allocates Shared Memory, and
+    starts the other collaborating processes of the Instance:
     <glossterm linkend="glossary-background-writer">Background Writer</glossterm>,
     <glossterm linkend="glossary-checkpointer">Checkpointer</glossterm>,
     <glossterm linkend="glossary-wal-writer">WAL Writer</glossterm>,
@@ -39,9 +43,10 @@
     <glossterm linkend="glossary-autovacuum">Autovacuum</glossterm>,
     <glossterm linkend="glossary-stats-collector">Statistics Collector</glossterm>,
     <glossterm linkend="glossary-logger">Logger</glossterm>, and more.
-    Later, the Postmaster starts
+    Later, the Postmaster listens on its configured system port and in response
+    to client connection attempts launches
     <glossterm linkend="glossary-backend">Backend</glossterm> processes
-    which communicate with clients and handle their requests.
+    to which it delegates authentication, communication, and the handling of their requests.
     <xref linkend="tutorial-ram-proc-file-figure"/> visualizes the processes
     of an Instance and the main aspects of their collaboration.
    </para>
@@ -62,14 +67,6 @@
     </mediaobject>
    </figure>
 
-   <para>
-    When a client application tries to connect to a
-    <glossterm linkend="glossary-database">database</glossterm>,
-    this request is handled initially by the Postmaster. It
-    starts a new Backend process, which handles all further
-    client's requests.
-   </para>
-
    <para>
     Client requests like <command>SELECT</command> or
     <command>UPDATE</command> usually lead to the
@@ -77,16 +74,16 @@
     by the client's backend process. Reads involve a page-level
     cache, located in Shared Memory (for details see:
     <xref linkend="sysvipc"/>) for the benefit of all processes
-    in the instance. Writes also use this cache, in addition
+    in the Instance. Writes also use this cache, in addition
     to a journal, called the write-ahead-log or WAL.
    </para>
 
    <para>
     Shared Memory is limited in size and it can become necessary
     to evict pages. As long as the content of such pages hasn't
-    changed, this is not a problem. But in Shared Memory also
-    write actions take place. Modified pages are called dirty
-    pages or dirty buffers and before they can be evicted they
+    changed, this is not a problem. But writes directly modify
+    the pages in Shared Memory. Modified pages are called dirty
+    pages (or dirty buffers) and before they can be evicted they
     must be written to disk. This happens regularly by the
     Checkpointer and the Background Writer processes to ensure
     that the disk version of the pages are up-to-date.
@@ -98,7 +95,7 @@
     <glossterm linkend="glossary-wal-record">WAL record</glossterm>
     is created from the delta-information (difference between the
     old and the new content) and stored in another area of
-    Shared Memory. The parallel running WAL Writer process
+    Shared Memory. The concurrently running WAL Writer process
     reads them and appends them to the end of the current
     <glossterm linkend="glossary-wal-record">WAL file</glossterm>.
     Such sequential writes are faster than writes to random
@@ -108,8 +105,8 @@
    </para>
 
    <para>
-    Second, the transfer of dirty buffers from Shared Memory to
-    files must take place. This is the primary task of the
+    Second, the Instance transfers dirty buffers from Shared Memory to
+    files. This is the primary task of the
     Background Writer process. Because I/O activities can block
     other processes, it starts periodically and
     acts only for a short period. Doing so, its extensive (and
@@ -123,14 +120,8 @@
     <glossterm linkend="glossary-checkpoint">Checkpoints</glossterm>.
     A Checkpoint is a point in time when all older dirty buffers,
     all older WAL records, and finally a special Checkpoint record
-    are written and flushed to disk. Heap and index files,
-    and WAL files are now in sync.
-    Older WAL is no longer required. In other words,
-    a possibly occurring recovery, which integrates the delta
-    information of WAL into heap and index files, will happen
-    by replaying only WAL past the last-recorded checkpoint.
-    This limits the amount of WAL to be replayed
-    during recovery in the event of a crash.
+    are written and flushed to disk.
+    Older WAL files are no longer required to recover the system from a crash.
    </para>
 
    <para>
@@ -141,8 +132,10 @@
     less common). Options and details are covered
     in the backup and restore section (<xref linkend="backup"/>).
     For our purposes here, just note that the WAL Archiver process
-    can be enabled and configured to run a script on filled WAL
-    files &mdash; usually to copy them to a remote location.
+    can be enabled and configured to run a script on completed WAL
+    files &mdash; usually to copy them to a remote location. Note
+    that when a Checkpoint record is written to the WAL the current
+    file is immediately completed.
    </para>
 
    <para>
@@ -163,23 +156,35 @@
    <title>The logical Perspective: Cluster, Database, Schema</title>
 
    <para>
-    A <glossterm linkend="glossary-server">server</glossterm> contains one or more
-    <glossterm linkend="glossary-db-cluster">database clusters</glossterm>
-    (<glossterm linkend="glossary-db-cluster">clusters</glossterm>
-    for short). Each cluster contains three or more
-    <glossterm linkend="glossary-database">databases</glossterm>.
-    Each database can contain many
-    <glossterm linkend="glossary-schema">schemas</glossterm>.
-    A schema can contain
-    <glossterm linkend="glossary-table">tables</glossterm>,
+    A <glossterm linkend="glossary-server">Server</glossterm> contains one or more
+    <glossterm linkend="glossary-db-cluster">Database Clusters</glossterm>
+    (<glossterm linkend="glossary-db-cluster">Clusters</glossterm>
+    for short). By default each newly initialized Cluster contains three
+    <glossterm linkend="glossary-database">databases</glossterm>
+    (one interactive and two templates, see <xref linkend="app-initdb"/>).
+    Each database can contain many user-writable
+    <glossterm linkend="glossary-schema">schemas</glossterm>
+    (public, by name and permissiveness, by default), the system
+    generated user-facing schemas <literal>pg_catalog</literal>,
+    <literal>pg_temp</literal>, and <literal>information_schema</literal>,
+    and some more system schemas.
+    <glossterm linkend="glossary-table">Tables</glossterm>,
     <glossterm linkend="glossary-view">views</glossterm>, and a lot
-    of other objects. Each table or view belongs to a single schema
-    only; they cannot belong to another schema as well. The same is
-    true for the schema/database and database/cluster relation.
+    of other objects uniquely reside in a single schema.
     <xref linkend="tutorial-cluster-db-schema-figure"/> visualizes
     this hierarchy.
    </para>
 
+   <para>
+    <!-- is the para helpful at this position? -->
+    Client connections act at the database level and can access
+    its schemas simultaneously. Special techniques like
+    <link linkend="sql-createforeigndatawrapper">foreing data wrapper</link>
+    or <link linkend="dblink">dblink</link> are required
+    to access multiple databases, even within the same Cluster,
+    from a single client connection.
+   </para>
+
    <figure id="tutorial-cluster-db-schema-figure">
     <title>Cluster, Database, Schema</title>
     <mediaobject>
@@ -197,31 +202,30 @@
    </figure>
 
    <para>
-    A cluster is the outer container for a
+    A Cluster is the outer container for a
     collection of databases. Clusters are created by the command
     <xref linkend="app-initdb"/>.
    </para>
 
    <para>
     <literal>template0</literal> is the very first
-    database of any cluster. Database <literal>template0</literal>
-    is created during the initialization phase of the cluster.
+    database of any Cluster. It
+    is created during the initialization phase of the Cluster.
     In a second step, database <literal>template1</literal> is generated
     as a copy of <literal>template0</literal>, and finally database
     <literal>postgres</literal> is generated as a copy of
     <literal>template1</literal>. Any
     <glossterm linkend="app-createdb">new databases</glossterm>
-    of the cluster that a user might need,
+    of the Cluster that a user might need,
     such as <literal>my_db</literal>, will be copied from the
     <literal>template1</literal> database. Due to the unique
     role of <literal>template0</literal> as the pristine original
-    of all other databases, no client can connect to it.
+    of all other databases, no client is allowed to connect to it.
    </para>
 
    <para>
-    Every database must contain at least one schema because all
     <glossterm linkend="glossary-sql-object">SQL Objects</glossterm>
-    must be contained in a schema.
+    are contained in a schema.
     Schemas are namespaces for SQL objects and ensure
     (with one exception) that the SQL object names are used only once within
     their scope across all types of SQL objects. E.g., it is not possible
@@ -243,26 +247,46 @@
     without using an explicit schema name. <literal>public</literal>
     should not contain user-defined SQL objects. Instead, it is
     recommended to create a separate schema that holds individual
-    objects like application-specific tables or views.
+    objects like application-specific tables or views. To access
+    objects in such a schema they can be fully qualified, e.g.
+    <literal>my_schema.my_table</literal>, or by changing the
+    <link linkend="ddl-schemas-path">schema search path</link>.
+   </para>
+
+   <para>
     <literal>pg_catalog</literal> is a schema for all tables and views of the
     <glossterm linkend="glossary-system-catalog">System Catalog</glossterm>.
-    <literal>information_schema</literal> is a schema for several
-    tables and views of the System Catalog in a way that conforms
-    to the SQL standard.
+    <literal>information_schema</literal> is a similar schema. It
+    contains several tables and views of the System Catalog in a
+    way that conforms to the SQL standard.
    </para>
 
    <para>
-    There are many different SQL object
-    types: <firstterm>database, schema, table, view, materialized
-    view, index, constraint, sequence, function, procedure,
-    trigger, role, data type, operator, tablespace, extension,
-    foreign data wrapper</firstterm>, and more. A few of them, the
+    There are many different SQL object types:
+    <glossterm linkend="glossary-database">database</glossterm>,
+    <glossterm linkend="glossary-schema">schema</glossterm>,
+    <glossterm linkend="glossary-table">table</glossterm>,
+    <glossterm linkend="glossary-view">view</glossterm>,
+    <glossterm linkend="glossary-materialized-view">materialized view</glossterm>,
+    <glossterm linkend="glossary-index">index</glossterm>,
+    <glossterm linkend="glossary-constraint">constraint</glossterm>,
+    <glossterm linkend="glossary-sequence">sequence</glossterm>,
+    <glossterm linkend="glossary-function">function</glossterm>,
+    <glossterm linkend="glossary-procedure">procedure</glossterm>,
+    <glossterm linkend="glossary-trigger">trigger</glossterm>,
+    <glossterm linkend="glossary-role">role</glossterm>,
+    <glossterm linkend="datatype">data type</glossterm>,
+    <glossterm linkend="functions">operator</glossterm>,
+    <glossterm linkend="glossary-tablespace">tablespace</glossterm>,
+    <glossterm linkend="glossary-extension">extension</glossterm>,
+    <glossterm linkend="glossary-foreign-data-wrapper">foreign data wrapper</glossterm>,
+    and more. A few of them, the
     <firstterm>Global SQL Objects</firstterm>, are outside of the
     strict hierarchy: All <firstterm>database names</firstterm>,
     all <firstterm>tablespace names</firstterm>, and all
     <firstterm>role names</firstterm> are automatically
-    available throughout the cluster, independent from
-    the database or schema in which they were defined originally.
+    available throughout the Cluster, not just the database in which
+    the SQL command was executed.
     <xref linkend="tutorial-internal-objects-hierarchy-figure"/>
     shows the relation between the object types.
    </para>
@@ -286,7 +310,7 @@
   </sect1>
 
   <sect1 id="tutorial-directories">
-   <title>The physical Perspective: Directories and Files</title>
+   <title>The Physical Perspective: Directories and Files</title>
 
    <para>
     <productname>PostgreSQL</productname> organizes long-lasting (persistent)
@@ -297,7 +321,7 @@
     variable <literal>PGDATA</literal> points to this directory.
     The example shown in
     <xref linkend="tutorial-directories-figure"/> uses
-    <literal>data</literal> as the name of this root directory.
+    <literal>data</literal> as the name of the cluster's root directory.
    </para>
 
    <figure id="tutorial-directories-figure">
@@ -317,27 +341,29 @@
    </figure>
 
    <para>
-    <literal>data</literal> contains many subdirectories and
+    The cluster's root directory contains many subdirectories and
     some files, all of which are necessary to store long-lasting
-    as well as temporary data. The following paragraphs
-    describe the files and subdirectories in
-    <literal>data</literal>.
+    as well as temporary data. The root's name can be selected
+    as desired, but the names of its subdirectories and files
+    are more or less fix and detertermined by
+    <productname>PostgreSQL</productname>. The following
+    paragraphs describe the most important subdirectories
+    and files.
    </para>
 
    <para>
-    <literal>base</literal> is a subdirectory in which one
-    subdirectory per database exists. The names of those
+    <literal>base</literal> contains one
+    subdirectory per database. The names of those
     subdirectories consist of numbers. These are the internal
     Object Identifiers (OID), which are numbers to identify
-    the database definition in the
+    their definition in the
     <glossterm linkend="glossary-system-catalog">System Catalog</glossterm>.
    </para>
 
    <para>
-    Within the database-specific
-    subdirectories, there are many files: one or more for
-    every table and every index to store heap and index
-    data. Those files are accompanied by files for the
+    Within the database-specific subdirectories of <literal>base</literal>
+    there are many files: one or more for every table
+    and every index. Those files are accompanied by files for the
     <link linkend="storage-fsm">Free Space Maps</link>
     (suffixed <literal>_fsm</literal>) and
     <link linkend="storage-vm">Visibility Maps</link>
@@ -345,20 +371,25 @@
    </para>
 
    <para>
-    Another subdirectory is <literal>global</literal> which
+    Another subdirectory is <literal>global</literal>. It
     contains files with information about
     <glossterm linkend="glossary-sql-object">Global SQL Objects</glossterm>.
-    One type of such Global SQL Objects are
-    <glossterm linkend="glossary-tablespace">tablespaces</glossterm>.
-    In <literal>global</literal> there is information about
-    the tablespaces; not the tablespaces themselves.
+   </para>
+
+   <para>
+    In <literal>pg_tblspc</literal>, there are symbolic links
+    that point to directories that are outside of the root
+    directory tree, e.g. at a different disc. Files for tables
+    and indexes of non-default tablespaces reside there. As
+    previously mentioned, those defined within the default
+    tablespace reside in the database-specific subdirectories.
    </para>
 
    <para>
     The subdirectory <literal>pg_wal</literal> contains the
     <glossterm linkend="glossary-wal-file">WAL files</glossterm>.
     They arise and grow in parallel with data changes in the
-    cluster and remain as long as
+    Cluster and remain as long as
     they are required for recovery, archiving, or replication.
    </para>
 
@@ -370,19 +401,14 @@
    </para>
 
    <para>
-    In <literal>pg_tblspc</literal>, there are symbolic links
-    that point to directories containing SQL objects
-    that exist within a non-default tablespace.
-   </para>
-
-   <para>
-    In the root directory <literal>data</literal>
+    In the root directory
     there are also some files. In many cases, the configuration
-    files of the cluster are stored here. If the
-    instance is up and running, the file
+    files of the Cluster are stored here. If the
+    Instance is up and running, the file
     <literal>postmaster.pid</literal> exists here
+    (by default)
     and contains the process ID (pid) of the
-    Postmaster which started the instance.
+    Postmaster which started the Instance.
    </para>
 
    <para>
@@ -413,8 +439,8 @@
     <productname>PostgreSQL</productname> implements a
     sophisticated technique which avoids locking:
     <firstterm>Multiversion Concurrency Control</firstterm> (MVCC).
-    The advantage of MVCC
-    over technologies that use row locks becomes evident in multiuser OLTP
+    The advantage of MVCC over technologies that use row locks
+    becomes evident in multiuser Online Transaction Processing (OLTP)
     environments with a massive number of concurrent write
     actions. There, MVCC generally performs better than solutions
     using locks. In a <productname>PostgreSQL</productname>
@@ -439,15 +465,15 @@
    </para>
 
    <para>
-    When we speak about transaction IDs, you need to know that xids are like
-    sequences. Every new transaction receives the next number as its ID.
-    Therefore, this flow of xids represents the flow of transaction
-    start events over time. But keep in mind that xids are independent of
-    any time measurement &mdash; in milliseconds or otherwise. If you dive
-    deeper into <productname>PostgreSQL</productname>, you will recognize
-    parameters with names such as 'xxx_age'. Despite their names,
-    these '_age' parameters do not specify a period of time but represent
-    a certain number of transactions, e.g., 100 million.
+    Xids are sequences (with a reserved value to handle wrap-around
+    in pre-9.4 <productname>PostgreSQL</productname> versions).
+    Age computations involving them measure a transaction
+    count as opposed to a time interval (in milliseconds or otherwise).
+    If you dive deeper into <productname>PostgreSQL</productname>,
+    you will recognize parameters with names such as 'xxx_age'.
+    Despite their names, these '_age' parameters do not specify
+    a period of time but represent a certain number of transactions,
+    e.g., 100 million.
    </para>
 
    <para>
@@ -498,7 +524,7 @@
     executes an <command>UPDATE</command> of this row by
     changing the user data from <literal>'x'</literal> to
     <literal>'y'</literal>. According to the MVCC principles,
-    the data in the old version of the row is not changed!
+    the data in the old version of the row is not changed.
     The value <literal>'x'</literal> remains as it was before.
     Only <literal>xmax</literal> changes to <literal>135</literal>.
     Now, this version is treated as valid exclusively for
@@ -526,7 +552,7 @@
    <para>
     Finally, a row may be deleted by a <command>DELETE</command>
     command. Even in this case, all versions of the row remain as
-    before. Nothing is thrown away! Only <literal>xmax</literal>
+    before; nothing is thrown away. Only <literal>xmax</literal>
     of the last version is set to the xid of the <command>DELETE</command>
     transaction, which indicates that (if committed) it is only visible to
     transactions with xids older than that (from
@@ -545,7 +571,8 @@
     Over time, also the older ones get out of scope
     for ALL transactions and therefore become unnecessary.
     Nevertheless, they do exist physically on the disk and occupy
-   space.
+    space. They are called <firstterm>dead rows</firstterm> and are part
+    of the <glossterm linkend="glossary-bloat">bloat</glossterm>.
    </para>
 
    <para>
@@ -560,12 +587,7 @@
       <firstterm>row versions</firstterm> are valid (visible) for transactions.
       This range doesn't imply any direct temporal meaning;
       the sequence of xids reflects only the sequence of
-      transaction begin events. As
-      xids grow, old row versions get out of scope over time.
-      If an old row version is no longer relevant for ANY existing
-      transactions, it can be marked <firstterm>dead</firstterm>. The
-      space occupied by dead row versions is part of the
-      <glossterm linkend="glossary-bloat">bloat</glossterm>.
+      transaction begin events.
      </simpara>
     </listitem>
 
@@ -581,9 +603,9 @@
      <simpara>
       Nothing is removed &mdash; with the consequence that the database
       occupies more and more disk space. It is obvious that
-      this behavior has to be corrected in some
-      way. The next chapter explains how <firstterm>autovacuum</firstterm>
-      fulfills this task.
+      this behavior has to be corrected in some way. The next
+      chapter explains how <firstterm>vacuum</firstterm> and
+      <firstterm>autovacuum</firstterm> fulfill this task.
      </simpara>
     </listitem>
 
@@ -601,12 +623,12 @@
     This chapter explains how the SQL command
     <command>VACUUM</command> and the automatically running
     <firstterm>Autovacuum</firstterm> processes clean up
-    and avoid continued growth.
+    and prevent continued growth.
    </para>
 
    <note>
     <para>
-     Autovacuum runs automatically by
+     Autovacuum runs automatically, by
      default. Its default parameters as well as those for
      <command>VACUUM</command> are appropriate for most standard
      situations. Therefore a novice database manager can
@@ -617,11 +639,11 @@
 
    <para>
     Client processes can issue the SQL command <command>VACUUM</command>
-    at arbitrary points in time. DBAs do this when they recognize
+    at any time. DBAs do this when they recognize
     special situations, or they start it in batch jobs which run
-    periodically. Autovacuum processes run as part of the
-    <link linkend="glossary-instance">Instance</link> at the server.
-    There is a constantly running Autovacuum daemon. It continuously
+    periodically. Additionally, there is a constantly running
+    Autovacuum daemon which is part of the
+    <link linkend="glossary-instance">Instance</link>. It continuously
     monitors the state of all databases based on values that are collected by the
     <link linkend="glossary-stats-collector">Statistics Collector</link>
     and starts Autovacuum processes whenever it detects
@@ -1234,7 +1256,7 @@ UPDATE accounts SET balance = balance + 100.00 WHERE name = 'Bob';
    <para>
     Lastly, it is worth noticing that changes done by a
     committed transaction will survive all failures in the application or
-    database cluster. The next chapter explains the
+    the Database Cluster. The next chapter explains the
     <glossterm linkend="glossary-durability">durability</glossterm>
     guarantees.
    </para>
@@ -1276,7 +1298,7 @@ UPDATE accounts SET balance = balance + 100.00 WHERE name = 'Bob';
 
    <bridgehead renderas="sect3">Instance failure</bridgehead>
    <para>
-    The instance may suddenly fail because of <emphasis>power off</emphasis>
+    The Instance may suddenly fail because of <emphasis>power off</emphasis>
     or other problems. This will affect all running processes, the RAM,
     and possibly the consistency of disk files.
    </para>
@@ -1284,7 +1306,7 @@ UPDATE accounts SET balance = balance + 100.00 WHERE name = 'Bob';
    <para>
     After a restart, <productname>PostgreSQL</productname>
     automatically recognizes that the last shutdown of the
-    instance did not happen as expected: files might not be
+    Instance did not happen as expected: files might not be
     closed properly and the <literal>postmaster.pid</literal>
     file unexpectedly exists. <productname>PostgreSQL</productname>
     tries to clean up the situation. This is possible because
@@ -1330,7 +1352,7 @@ UPDATE accounts SET balance = balance + 100.00 WHERE name = 'Bob';
    <para>
     They obviously need a backup. How to take such a backup
     and use it as a starting point for a recovery of the
-    cluster is explained in more detail in the next
+    Cluster is explained in more detail in the next
     <link linkend="tutorial-backup">chapter</link>.
    </para>
 
@@ -1396,7 +1418,7 @@ UPDATE accounts SET balance = balance + 100.00 WHERE name = 'Bob';
    <para>
     You can use any appropriate OS tool to create a
     <link linkend="backup-file">copy</link>
-    of the cluster's directory structure and files. In
+    of the Cluster's directory structure and files. In
     case of severe problems such a copy can serve as
     the source of recovery. But in order to get a
     <emphasis>USABLE</emphasis> backup by this method,
@@ -1416,7 +1438,7 @@ UPDATE accounts SET balance = balance + 100.00 WHERE name = 'Bob';
    <para>
     The tool <command>pg_dump</command> is able to take a
     <link linkend="backup-dump">copy</link>
-    of the complete cluster or certain parts of it. It stores
+    of the complete Cluster or certain parts of it. It stores
     the copy in the form of SQL commands like <command>CREATE</command>
     and <command>COPY</command>. It runs in
     parallel with other processes, in its own transaction.
@@ -1430,9 +1452,9 @@ UPDATE accounts SET balance = balance + 100.00 WHERE name = 'Bob';
 
    <para>
     The main advantage over the other two methods is that it
-    can pick parts of the cluster, e.g., a single table or one
+    can pick parts of the Cluster, e.g., a single table or one
     database. The other two methods work only at the level of
-    the complete cluster.
+    the complete Cluster.
    </para>
 
    <bridgehead renderas="sect2">Continuous archiving based on pg_basebackup and WAL files</bridgehead>
@@ -1447,7 +1469,7 @@ UPDATE accounts SET balance = balance + 100.00 WHERE name = 'Bob';
     <firstterm>basebackup</firstterm> with the tool
     <command>pg_basebackup</command>. The result is a
     directory structure plus files which contain a
-    consistent copy of the original cluster.
+    consistent copy of the original Cluster.
     <command>pg_basebackup</command> runs in
     parallel with other processes in its own transaction.
    </para>
@@ -1456,9 +1478,9 @@ UPDATE accounts SET balance = balance + 100.00 WHERE name = 'Bob';
     The second step is recommended but not necessary. All
     changes to the data are stored in WAL files. If you
     continuously save such WAL files, you have the history
-    of the cluster. This history can be applied to a
+    of the Cluster. This history can be applied to a
     basebackup in order to recreate
-    any state of the cluster between the time of
+    any state of the Cluster between the time of
     <command>pg_basebackup</command>'s start time and
     any later point in time. This technique
     is called 'Point-in-Time Recovery (PITR)'.
@@ -1478,7 +1500,7 @@ UPDATE accounts SET balance = balance + 100.00 WHERE name = 'Bob';
    </para>
 
    <para>
-    If it becomes necessary to restore the cluster, you have to
+    If it becomes necessary to restore the Cluster, you have to
     copy the basebackup and the archived WAL files to
     their original directories. The configuration of this
     <link linkend="backup-pitr-recovery">recovery procedure</link>
