diff --git a/doc/src/sgml/architecture.sgml b/doc/src/sgml/architecture.sgml
index b6c0eb4a31..e547a87d08 100644
--- a/doc/src/sgml/architecture.sgml
+++ b/doc/src/sgml/architecture.sgml
@@ -13,42 +13,26 @@
   <sect1 id="tutorial-ram-proc-file">
    <title>Collaboration of Processes, RAM, and Files</title>
    <para>
-    In a client/server architecture
-    clients do not have direct access to stored data. Instead,
-    they send requests to the server and receive
-    the requested data in response. In the case of
-    <productname>PostgreSQL</productname>, the server launches a
-    single process for each connected client, referred to as a
-    <glossterm linkend="glossary-backend">Backend process</glossterm>.
-
-
-    <!-- DGJ: this whole next paragraph bothers me but I cannot justify
-         simply removing it nor have a possibly better suggestion.
-         In particular I disagree with categorizing this is a
-         "close" and "tightly-coupled" relationship -->
-
-
-    It acts in close cooperation with the
-    <glossterm linkend="glossary-instance">instance</glossterm> which
-    is a group of tightly coupled server-side processes plus a
-    <glossterm linkend="glossary-shared-memory">Shared Memory</glossterm>
-    area located in RAM.
-    Notably, PostgreSQL does not utilize application threading within its
-    implementation.
-   </para>
-
-
-     <!-- DGJ: I've gotten the impression firstterm 
-          is overused, probably as a result of copy-paste -->
-
-
-   <para>
-    During <firstterm>instance</firstterm> startup time, the
-    <glossterm linkend="glossary-postmaster">Postmaster</glossterm>
-    process loads the
-    configuration files, allocates
-    <firstterm>Shared Memory</firstterm>,
-    and starts supporting background processes:
+    In a client/server architecture clients do not have direct access
+    to database files and the data stored in them. Instead, they send
+    requests to the server and receive the requested data in the response.
+    In the case of <productname>PostgreSQL</productname>, the server
+    launches a single process for each client connection, referred to as a
+    <glossterm linkend="glossary-backend">Backend</glossterm> process.
+    Those Backend processes handle the client's requests by acting on the
+    <glossterm linkend="glossary-shared-memory">Shared Memory</glossterm>.
+    This leads to other activities (file access, WAL, vacuum, ...) of the
+    <glossterm linkend="glossary-instance">Instance</glossterm>. The
+    Instance is a group of server-side processes acting on a common
+    Shared Memory. Notably, PostgreSQL does not utilize application
+    threading within its implementation.
+   </para>
+
+   <para>
+    The first step in an Instance start is the start of the
+    <glossterm linkend="glossary-postmaster">Postmaster</glossterm>.
+    He loads the configuration files, allocates Shared Memory, and
+    starts the other 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>,
@@ -56,8 +40,11 @@
     <glossterm linkend="glossary-autovacuum">Autovacuum</glossterm>,
     <glossterm linkend="glossary-stats-collector">Statistics Collector</glossterm>,
     <glossterm linkend="glossary-logger">Logger</glossterm>, and more.
-    <xref linkend="tutorial-ram-proc-file-figure"/> visualizes
-    the main aspects of their collaboration.
+    Later, the Postmaster starts
+    <glossterm linkend="glossary-backend">Backend</glossterm> processes
+    which communicate with clients and handle their requests.
+    <xref linkend="tutorial-ram-proc-file-figure"/> visualizes the processes
+    of an Instance and the main aspects of their collaboration.
    </para>
 
    <figure id="tutorial-ram-proc-file-figure">
@@ -77,155 +64,110 @@
    </figure>
 
    <para>
-
-
-    <!-- DGJ: This is detailed, but wrong.  Either use less detail or correct detail.
-              See header of postmaster.c
-    -->
-
-
     When a client application tries to connect to a
     <glossterm linkend="glossary-database">database</glossterm>,
-    this request is handled initially by the
-    <firstterm>Postmaster</firstterm> process. It checks authorization,
-    starts a new <firstterm>Backend process</firstterm>,
-    and instructs the client application to connect to it. All
-    further client requests go to this process and are handled
-    by it.
+    this request is handled initially by the Postmaster. He
+    starts a new Backend process and instructs the client
+    application to connect to it. All further client requests
+    go to this process and are handled by it.
    </para>
 
    <para>
     Client requests like <command>SELECT</command> or
     <command>UPDATE</command> usually lead to the
-    necessity to read or write some data. In a first attempt
-    the client's <firstterm>Backend process</firstterm> tries
-    to get the information out of <firstterm>Shared
-    Memory</firstterm>. This <firstterm>Shared
-    Memory</firstterm> is a mirror of parts of the
-    <glossterm linkend="glossary-heap">heap</glossterm> and
-    <glossterm linkend="glossary-index">index</glossterm> files.
-    Because files are often larger than memory, it's likely that
-    the desired information is not (completely) available
-    in RAM. In this case the <firstterm>Backend process</firstterm>
-    must transfer additional file pages to
-    <firstterm>Shared Memory</firstterm>. Files are physically
-    organized in pages. Every transfer between files and
-    RAM is performed in units of complete pages; such transfers
-    do not change the size or layout of pages.
-   </para>
-
-   <para>
-    Reading file pages is much slower than reading
-    RAM. This is the primary motivation for the usage of
-    <firstterm>Shared Memory</firstterm>. As soon as one
-    of the <firstterm>Backend processes</firstterm> has
-    read pages into memory, those pages become available for all
-    other <firstterm>Backend processes</firstterm> for direct
-    access in RAM.
-   </para>
-
-   <para>
-    <firstterm>Shared Memory</firstterm> is limited in size.
-    Sooner or later, it becomes necessary to overwrite old RAM
-    pages. As long as the content of such pages hasn't
-    changed, this is not a problem. But in
-    <firstterm>Shared Memory</firstterm> also write
-    actions take place
-    &mdash; performed by any of the <firstterm>Backend
-    processes</firstterm> (or an
-    <firstterm>autovacuum</firstterm> process,
-    or other processes). Such modified pages are called
-    <firstterm>dirty pages</firstterm>.
-    Before <firstterm>dirty pages</firstterm> can be overwritten,
-    they must be written back to disk. This is a two-step process.
-   </para>
+    necessity to read or write some data. This is carried out
+    by the client's backend process. Reads involve a page-level
+    cache housed in Shared Memory (for details see:
+    <xref linkend="sysvipc"/>) for the benefit of all processes
+    in the instance. Writes also involve this cache, in additional
+    to a journal, called a write-ahead-log or WAL.
+   </para>
+
+   <para>
+    Shared Memory is limited in size. Thus, it becomes 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
+    must be written back to disk. This happens regularly by the
+    Background Writer and the Checkpointer process to ensure
+    that the disk version of the pages are kept up-to-date.
+    The synchronisation from RAM to disk consists of two steps.
+   </para>
+
+<!-- DGJ: WAL should already be done well before page
+          eviction/overwriting comes into play.
+          This is good material but seems misplaced.
+     JuP: Really misplaced? Don't think so.
+-->
 
    <para>
     First, whenever the content of a page changes, a
     <glossterm linkend="glossary-wal-record">WAL record</glossterm>
-    is created out
-    of the delta-information (difference between the old and
-    the new content) and stored in another area of
-    <firstterm>Shared Memory</firstterm>. These
-    <firstterm>WAL records</firstterm> are read by the
-    <firstterm>WAL Writer</firstterm> process,
-    which runs in parallel to the <firstterm>Backend
-    processes</firstterm> and other processes of
-    the <firstterm>Instance</firstterm>. It writes
-    the continuously arising <firstterm>WAL records</firstterm> to
-    the end of the current
+    is created out of 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
+    reads them and appends them to the end of the current
     <glossterm linkend="glossary-wal-record">WAL file</glossterm>.
-    Because this writing is sequential, it is much
-    faster than the more or less random access
-    to data files with <firstterm>heap</firstterm>
-    and <firstterm>index</firstterm> information.
-    As mentioned, this WAL-writing happens
-    in an independent process. All
-    <firstterm>WAL records</firstterm> created out of one
-    <firstterm>dirty page</firstterm> must be transferred
-    to disk before the <firstterm>dirty page</firstterm>
-    itself can be transferred to disk.
-   </para>
-
-   <para>
-    Second, the transfer of <firstterm>dirty buffers</firstterm>
-    from <firstterm>Shared Memory</firstterm> to file must
-    take place. This is the primary task of the
-    <firstterm>Background Writer</firstterm> process. Because
-    I/O activities can block other processes significantly,
-    it starts periodically and acts only for a short period.
-    Doing so, its expensive I/O activities are spread over
-    time, avoiding debilitating I/O peaks. Also, the <firstterm>
-    Checkpointer</firstterm> process transfers
-    <firstterm>dirty buffers</firstterm> to file &mdash;
-    see next paragraph.
-   </para>
-
-   <para>
-    The <firstterm>Checkpointer</firstterm> creates
+    Such sequential writes are much faster than writes to random
+    positions of heap and index files. All WAL records created
+    out of one dirty page must be transferred to disk before the
+    dirty page itself can be transferred to disk in the second step.
+   </para>
+
+   <para>
+    Second, the transfer of dirty buffers from Shared Memory to
+    files must take place. This is the primary task of the
+    Background Writer process. Because I/O activities can block
+    other processes significantly, it starts periodically and
+    acts only for a short period. Doing so, its extensive (and
+    expensive) I/O activities are spread over time, avoiding
+    debilitating I/O peaks. Also, the Checkpointer process
+    transfers dirty buffers to file.
+   </para>
+
+   <para>
+    The Checkpointer creates
     <glossterm linkend="glossary-checkpoint">Checkpoints</glossterm>.
-    A <firstterm>Checkpoint</firstterm>
-    is a point in time when all older <firstterm>dirty buffers</firstterm>,
-    all older <firstterm>WAL records</firstterm>, and
-    finally a special <firstterm>Checkpoint record</firstterm>
-    have been written and flushed to disk.
-    After a <firstterm>Checkpoint</firstterm>, we say
-    data files and <firstterm>WAL files</firstterm> are in sync.
-    In case of a recovery (after a crash of the instance)
-    it can be relied upon that the information of all
-    <firstterm>WAL records</firstterm> preceding
-    the last <firstterm>Checkpoint record</firstterm>
-    were already integrated into the data files. This
-    speeds up the recovery.
+    A Checkpoint is a point in time when all older dirty buffers,
+    all older WAL records, and finally a special Checkpoint record
+    have been written and flushed to disk. Heap and index files
+    on the one hand and WAL files on the other hand are in sync.
+    Previous 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
+    on top of the current heap and files. This speeds up recovery.
    </para>
 
    <para>
-    As a result of data changes,
-    <firstterm>WAL records</firstterm> arise and get written
-    to <firstterm>WAL files</firstterm>.
-    Those <firstterm>WAL files</firstterm> &mdash; in combination with
-    a previously taken <firstterm>Base Backup</firstterm> &mdash;
-    are necessary to restore a database after a crash of the
-    disk on which data files have been stored. Therefore it is
-    recommended to transfer a copy of the
-    <firstterm> WAL files</firstterm>
-    to a second, independent place. The purpose of the
-    <firstterm>WAL Archiver</firstterm> process is to perform
-    this copy action.
+    While the Checkpointer ensures that a running system can crash
+    and restart itself in a valid state, the administrator needs
+    to handle the case where the heap and files themselves become
+    corrupted (and possibly the locally written WAL, though that is
+    less common). The options and details are covered extensively
+    in the backup and restore section (<xref linkend="backup"/>).
+    For our purposes here, note just 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.
    </para>
 
+
+<!-- DGJ: after the heavy focus on client processes and data these two
+          seem to come out of left field.  Skipping over for now.
+     JuP: Don't skip, we want to explain all elements of the graphic.
+-->
+
    <para>
-    The <firstterm>Statistics Collector</firstterm> collects
-    counters about accesses to <firstterm>SQL objects</firstterm>
-    like tables, rows, indexes, pages, and more. It stores the
-    obtained information in system tables.
+    The Statistics Collector collects counters about accesses to
+    SQL objects like tables, rows, indexes, pages, and more. It
+    stores the obtained information in system tables.
    </para>
 
    <para>
-    The <firstterm>Logger</firstterm> writes
-    text lines about serious and less serious events which can happen
-    during database access, e.g., wrong password, no permission,
-    long-running queries, etc.
+    The Logger writes text lines about serious and less serious
+    events which can happen during database access, e.g., wrong
+    password, no permission, long-running queries, etc.
    </para>
 
   </sect1>
@@ -286,46 +228,40 @@
     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 can connect to it.
    </para>
 
    <para>
-    Every database must contain <glossterm linkend="glossary-schema">
-    at least one schema</glossterm> because
-    schemas contain the other
-    <glossterm linkend="glossary-sql-object">SQL Objects</glossterm>.
-    Schemas are namespaces for
-    their SQL objects and ensure &mdash; with one
-    exception &mdash; that within their scope, names are used only once across all
-    types of SQL objects. E.g., it is not possible
+    Every database must contain at least one schema because all
+    <glossterm linkend="glossary-sql-object">SQL Objects</glossterm>
+    are contained in a schema.
+    Schemas are namespaces for their SQL objects and ensure
+    (with one exception) that within their scope names are used
+    only once across all types of SQL objects. E.g., it is not possible
     to have a table <literal>employee</literal> and a view
-    <literal>employee</literal> within the same
-    schema. But it is possible to have
-    two tables <literal>employee</literal> in different
-    schemas. In this case, the two tables
+    <literal>employee</literal> within the same schema. But it is
+    possible to have two tables <literal>employee</literal> in
+    different schemas. In this case, the two tables
     are separate objects and independent of each
     other. The only exception to this cross-type uniqueness is that
     <glossterm linkend="glossary-unique-constraint">unique constraints
-    </glossterm> and the according <firstterm>unique index</firstterm>
-    use the same name.
+    </glossterm> and the according unique index
+    (<xref linkend="indexes-unique"/>) use the same name.
    </para>
 
    <para>
     Some schemas are predefined. <literal>public</literal>
-    acts as the default schema and contains all
-    <firstterm>SQL objects</firstterm> which are created
-    within <literal>public</literal> or 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. <literal>pg_catalog</literal> is a schema for all tables
-    and views of the <glossterm linkend="glossary-system-catalog">
-    System Catalog</glossterm>.
+    acts as the default schema and contains all SQL objects
+    which are created within <literal>public</literal> or
+    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.
+    <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 <firstterm>System Catalog</firstterm>
-    in a way that conforms to the SQL standard.
+    tables and views of the System Catalog in a way that conforms
+    to the SQL standard.
    </para>
 
    <para>
@@ -334,11 +270,11 @@
     view, index, constraint, sequence, function, procedure,
     trigger, role, data type, operator, tablespace, extension,
     foreign data wrapper</firstterm>, and more. A few of them, the
-    <firstterm>Global SQL Objects</firstterm>,
-    are outside of the strict hierarchy:
-    All database names, all tablespace names, and all role names
-    are automatically known and available throughout the
-    cluster, independent from
+    <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 known and
+    available throughout the cluster, independent from
     the database or schema in which they where defined originally.
     <xref linkend="tutorial-internal-objects-hierarchy-figure"/>
     shows the relation between the object types.
@@ -369,7 +305,7 @@
     <productname>PostgreSQL</productname> organizes long-lasting
     data as well as volatile state information about transactions
     or replication actions in the file system. Every
-    <firstterm>Cluster</firstterm> has its root directory
+    <xref linkend="glossary-db-cluster"/> has its root directory
     somewhere in the file system. In many cases, the environment
     variable <literal>PGDATA</literal> points to this directory.
     The example shown in
@@ -427,8 +363,8 @@
     subdirectories, there are files containing information about
     <glossterm linkend="glossary-sql-object">Global SQL Objects</glossterm>.
     One type of such Global SQL Objects are
-    <firstterm>tablespaces</firstterm>. In
-    <literal>global</literal> there is information about
+    <glossterm linkend="glossary-tablespace">tablespaces</glossterm>.
+    In <literal>global</literal> there is information about
     the tablespaces, not the tablespaces themselves.
    </para>
 
@@ -443,14 +379,14 @@
    <para>
     The subdirectory <literal>pg_xact</literal> contains
     information about the status of each transaction:
-    in_progress, committed, aborted, or sub_committed.
+    <literal>in_progress</literal>, <literal>committed</literal>,
+    <literal>aborted</literal>, or <literal>sub_committed</literal>.
    </para>
 
    <para>
     In <literal>pg_tblspc</literal>, there are symbolic links
-    that point to directories containing such<firstterm>
-    SQL objects</firstterm> that are created within
-    tablespaces.
+    that point to directories containing such SQL objects
+    that are created within tablespaces.
    </para>
 
    <para>
@@ -474,7 +410,7 @@
    <title>MVCC &mdash; Multiversion Concurrency Control</title>
 
    <para>
-    In most cases, <productname>PostgreSQL</productname> based applications
+    In most cases, <productname>PostgreSQL</productname> databases
     support many clients at the same time. Therefore, it is necessary to
     protect concurrently running requests from unwanted overwriting
     of other's data as well as from reading inconsistent data. Imagine an
@@ -533,7 +469,7 @@
    </para>
 
    <para>
-    The description in this chapter simplifies by omitting detail.
+    The description in this chapter simplifies by omitting some details.
     When many transactions are running simultaneously, things can
     get complicated. Sometimes transactions get aborted via
     <command>ROLLBACK</command> immediately or after a lot of other activities, sometimes
@@ -644,7 +580,7 @@
       xids grow, old row versions get out of scope over time.
       If an old row version is no longer valid for ALL existing
       transactions, it's called <firstterm>dead</firstterm>. The
-      space occupied by all dead row versions is called
+      space occupied by dead row versions is part of the
       <glossterm linkend="glossary-bloat">bloat</glossterm>.
      </simpara>
     </listitem>
@@ -680,13 +616,13 @@
     <glossterm linkend="glossary-bloat">bloat</glossterm>.
     This chapter explains how the SQL command
     <command>VACUUM</command> and the automatically running
-    <firstterm>autovacuum</firstterm> processes clean up
+    <firstterm>Autovacuum</firstterm> processes clean up
     by eliminating bloat.
    </para>
 
    <note>
     <para>
-     <firstterm>Autovacuum</firstterm> runs automatically by
+     Autovacuum runs automatically by
      default. Its default parameters as well as such for
      <command>VACUUM</command> fit well for most standard
      situations. Therefore a novice database manager can
@@ -696,30 +632,27 @@
    </note>
 
    <para>
-    Client processes can issue the SQL command <command>VACUUM</command> at arbitrary
-    points in time. DBAs do this when they recognize special situations,
-    or they start it in batch jobs which run periodically.
-    <firstterm>Autovacuum</firstterm> processes run as part of the
-    <link linkend="glossary-instance">instance</link> at the server.
-    There is a constantly running <firstterm>autovacuum</firstterm> daemon.
-    It permanently controls the state of all databases based on values that
-    are collected by the
+    Client processes can issue the SQL command <command>VACUUM</command>
+    at arbitrary points in 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 permanently
+    controls the state of all databases based on values that are collected by the
     <link linkend="glossary-stats-collector">Statistics Collector</link>
-    and starts <firstterm>autovacuum</firstterm> processes whenever it detects
+    and starts Autovacuum processes whenever it detects
     certain situations. Thus, it's a dynamic behavior of
     <productname>PostgreSQL</productname> with the intention to tidy
     up &mdash; whenever it is appropriate.
    </para>
 
    <para>
-    <command>VACUUM</command>, as well as
-    <firstterm>autovacuum</firstterm>, don't just eliminate bloat.
-    They perform additional tasks for minimizing future
+    <command>VACUUM</command>, as well as Autovacuum, don't just eliminate
+    bloat. They perform additional tasks for minimizing future
     I/O activities of themselves as well as of other processes.
-    This extra work can be done in a very efficient way
-    since in most cases the expensive physical access to pages
-    has taken place anyway to eliminate bloat.
-    The additional operations are:
+    This extra work can be done in a very efficient way since in most
+    cases the expensive physical access to pages has taken place anyway
+    to eliminate bloat. The additional operations are:
    </para>
 
    <itemizedlist>
@@ -758,7 +691,7 @@
     <emphasis>freeze</emphasis> is controlled by configuration
     parameters, runtime flags, and in extreme situations by
     the processes themselves. Because vacuum operations typically are I/O
-    intensive, which can hinder other activities, <firstterm>autovacuum</firstterm>
+    intensive, which can hinder other activities, Autovacuum
     avoids performing many vacuum operations in bulk. Instead,
     it carries out many small actions with time gaps in between.
     The SQL command <command>VACUUM</command> runs immediately
@@ -784,8 +717,8 @@
     <listitem>
      <simpara>
       <literal>xmax</literal> must contain an xid which is older
-      than the oldest xid of all
-      currently running transactions (min(pg_stat_activity.backend_xmin)).
+      than the oldest xid of all currently running transactions
+      <literal>(min(pg_stat_activity.backend_xmin))</literal>.
       This criterion guarantees that no existing or upcoming transaction
       will have read or write access to this row version.
      </simpara>
@@ -810,9 +743,9 @@
 
    <para>
     After the vacuum operation detects a superfluous row version, it
-    marks its space as free for future use of writing
-    actions. Only in rare situations (or in the case of <command>VACUUM FULL</command>),
-    is this space released to the operating system. In most cases,
+    marks its space as free for future use of writing actions. Only
+    in rare situations (or in the case of <command>VACUUM FULL</command>),
+    this space is released to the operating system. In most cases,
     it remains occupied by <productname>PostgreSQL</productname>
     and will be used by future <command>INSERT</command> or
     <command>UPDATE</command> commands concerning this row or a
@@ -860,7 +793,7 @@
 
      <listitem>
       <simpara>
-       When an <firstterm>autovacuum</firstterm> process acts. For optimization
+       When an Autovacuum process acts. For optimization
        purposes, it considers the Visibility Map in the same way as
        <command>VACUUM</command>. Additionally, it ignores tables with few modifications;
        see <xref linkend="guc-autovacuum-vacuum-threshold"/>,
@@ -877,7 +810,7 @@
     This logic only applies to row versions of the heap. Index entries
     don't use <literal>xmin/xmax</literal>. Nevertheless, such index
     entries, which would lead to outdated row versions, are released
-    accordingly.       (??? more explanations ???)
+    accordingly.
    </para>
 
    <para>
@@ -996,7 +929,8 @@
 
      <listitem>
       <simpara>
-       The transaction of <literal>xmin</literal> must be committed.
+       The transactions of <literal>xmin</literal> and
+       <literal>xmax</literal> must be committed.
       </simpara>
      </listitem>
     </itemizedlist>
@@ -1029,8 +963,8 @@
      </listitem>
      <listitem>
       <simpara>
-       When an <firstterm>autovacuum</firstterm> process runs. Such
-       a process acts in one of two modes:
+       When an Autovacuum process runs. Such a process acts in one
+       of two modes:
       </simpara>
 
       <itemizedlist>
@@ -1053,7 +987,7 @@
          <xref linkend="guc-autovacuum-freeze-max-age"/>
          (default: 200 million). The value of the oldest unfrozen
          xid is stored per table in <literal>pg_class.relfrozenxid</literal>.
-         In this <emphasis>aggressive mode</emphasis> <firstterm>autovacuum</firstterm>
+         In this <emphasis>aggressive mode</emphasis> Autovacuum
          processes all such pages of the selected table that are marked
          in the Visibility Map to potentially have bloat or unfrozen rows.
         </simpara>
@@ -1065,7 +999,7 @@
    </para>
 
    <para>
-    In the first two cases and with <firstterm>autovacuum</firstterm> in
+    In the first two cases and with Autovacuum in
     <emphasis>aggressive mode</emphasis>, the system knows
     to which value the oldest unfrozen xid has moved forward and
     logs the value in <literal>pg_class.relfrozenxid</literal>.
@@ -1093,13 +1027,11 @@
    <bridgehead renderas="sect2">Protection against Wraparound Failure</bridgehead>
 
    <para>
-    The <firstterm>autovacuum</firstterm> processes are initiated by the
-    constantly running <firstterm>autovacuum</firstterm> daemon.
-    If the daemon detects that for a table
-    <firstterm>autovacuum_freeze_max_age</firstterm> is exceeded, it
-    starts an <firstterm>autovacuum</firstterm> process in
-    <emphasis>aggressive mode</emphasis>
-    (see above) &mdash; even if <firstterm>autovacuum</firstterm> is disabled.
+    The Autovacuum processes are initiated by the constantly running
+    Autovacuum daemon. If the daemon detects that for a table
+    <literal>autovacuum_freeze_max_age</literal> is exceeded, it
+    starts an Autovacuum process in <emphasis>aggressive mode</emphasis>
+    (see above) &mdash; even if Autovacuum is disabled.
    </para>
 
    <bridgehead renderas="sect2">Visibility Map and Free Space Map</bridgehead>
@@ -1127,7 +1059,7 @@
 
    <para>
     The setting of the flags is silently done by <command>VACUUM</command>
-    and <firstterm>autovacuum</firstterm> during their bloat and freeze operations.
+    and Autovacuum during their bloat and freeze operations.
     This is done to speed up future vacuum actions,
     regular accesses to heap pages, and some accesses to
     the index. Every data-modifying operation on any row
@@ -1138,10 +1070,9 @@
     The <link linkend="glossary-fsm">Free Space Map</link>
     (FSM) tracks the amount of free space per page. It is
     organized as a highly condensed b-tree of (rounded) sizes.
-    As long as <command>VACUUM</command> or
-    <firstterm>autovacuum</firstterm> change the free space
-    on any processed page, they log the new values in
-    the FSM in the same way as all other writing
+    As long as <command>VACUUM</command> or Autovacuum change
+    the free space on any processed page, they log the new
+    values in the FSM in the same way as all other writing
     processes.
    </para>
 
@@ -1153,11 +1084,10 @@
     decisions for the generation of execution plans. This
     information can be gathered with the SQL commands
     <command>ANALYZE</command> or <command>VACUUM ANALYZE</command>.
-    But <firstterm>autovacuum</firstterm> processes also gather
+    But also Autovacuum processes gather
     such information. Depending on the percentage of changed rows
     per table <xref linkend="guc-autovacuum-analyze-scale-factor"/>,
-    the <firstterm>autovacuum</firstterm> daemon starts
-    <firstterm>autovacuum</firstterm> processes to collect
+    the Autovacuum daemon starts Autovacuum processes to collect
     statistics per table. This dynamic invocation of analyze
     operations allows <productname>PostgreSQL</productname> to
     adopt queries to changing circumstances.
@@ -1221,7 +1151,7 @@ UPDATE accounts SET balance = balance + 100.00 WHERE name = 'Bob';
 
    <para>
     The atomicity also affects the visibility of changes. No
-    connections running simultaneously to a data modifying
+    connection running simultaneously to a data modifying
     transaction will ever see any change before the
     transaction successfully executes a <command>COMMIT</command>
     &mdash; even in the lowest
@@ -1293,7 +1223,7 @@ UPDATE accounts SET balance = balance + 100.00 WHERE name = 'Bob';
     <command>ROLLBACK</command> command instead of a
     <command>COMMIT</command>. The <command>ROLLBACK</command>
     cancels the transaction, and all changes made so far remain
-    invisible forever; it's like they never happened. There
+    invisible forever; it is as if they had never happened. There
     is no need for the application to log its activities and
     undo every step of the transaction separately.
    </para>
@@ -1319,10 +1249,11 @@ UPDATE accounts SET balance = balance + 100.00 WHERE name = 'Bob';
    </para>
 
    <para>
-    There is an additional feature which defines transactions'
-    <link linkend="transaction-iso">isolation level</link>
-    to each other in a declarative way. It automatically
-    prevents applications from some strange situations.
+    There is the additional feature
+    '<link linkend="transaction-iso">isolation level</link>',
+    which separates transactions from each other in certain ways.
+    It automatically prevents applications from some strange
+    situations.
    </para>
 
    <para>
@@ -1405,19 +1336,21 @@ UPDATE accounts SET balance = balance + 100.00 WHERE name = 'Bob';
     are also in the files, but - as usual - they are never seen
     by any of the following transactions because uncommited
     changes are never shown. Such recovery actions run
-    completely automatically, it is not necessary that you
-    configure or start anything by yourself.
+    completely automatically, it is not necessary that a
+    database administrator configure or start anything by
+    himself.
    </para>
 
    <bridgehead renderas="sect3">Disk crash</bridgehead>
    <para>
     If a disk crashes, the course of action described previously
     cannot work. It is likely that the WAL files and/or the
-    data and index files are no longer available. You need
-    to take special actions to overcome such situations.
+    data and index files are no longer available. The
+    database administrator must take special actions to
+    overcome such situations.
    </para>
    <para>
-    You obviously need a backup. How to take such a backup
+    He obviously needs 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
     <link linkend="tutorial-backup">chapter</link>.
@@ -1428,13 +1361,12 @@ UPDATE accounts SET balance = balance + 100.00 WHERE name = 'Bob';
     It is conceivable that over time the disk gets full,
     and there is no room for additional data. In this case,
     <productname>PostgreSQL</productname> stops accepting
-    commands which change the data or even terminates
-    completely. No data loss or data corruption will
-    occur.
+    data-modifying commands or even terminates completely.
+    No data loss or data corruption will occur.
    </para>
    <para>
-    To come out of such a situation, you should remove
-    unused files from this disk. But you should never
+    To come out of such a situation, the administrator should
+    remove unused files from this disk. But he should never
     delete files from the
     <glossterm linkend="glossary-data-directory">data directory</glossterm>.
     Nearly all of them are necessary for the consistency
diff --git a/doc/src/sgml/start.sgml b/doc/src/sgml/start.sgml
index 8751410179..abb61445f2 100644
--- a/doc/src/sgml/start.sgml
+++ b/doc/src/sgml/start.sgml
@@ -76,30 +76,27 @@
       A process at the server site with the name
       <glossterm linkend="glossary-postmaster">Postmaster</glossterm>.
       <indexterm><primary>postgres</primary></indexterm>
+      <indexterm><primary>postmaster</primary></indexterm>
       It accepts connection requests from client applications, starts
       (<quote>forks</quote>) a new <glossterm linkend="glossary-backend">
-      Backend process</glossterm> for each of them, and passes
+      Backend</glossterm> process for each of them, and passes
       the connection to it. From that point on, the client and the new
-      <firstterm>Backend process</firstterm>
-      communicate directly without intervention by the original
-      <firstterm>postgres</firstterm> process. Thus, the
-      <firstterm>postgres</firstterm> process is always running, waiting
-      for new client connections, whereas clients and associated
-      <firstterm>Backend processes</firstterm> come and go.
-      (All of this is of course invisible to the user. We only mention it
-      here for completeness.)
+      Backend process communicate directly without intervention by the original
+      Postmaster process. Thus, the Postmaster process is always running,
+      waiting for new client connections, whereas clients and associated
+      Backend processes come and go. (All of this is of course invisible
+      to the user. We only mention it here for completeness.)
      </para>
     </listitem>
 
     <listitem>
      <para>
       A group of processes at the server site, the <glossterm
-      linkend="glossary-instance">instance</glossterm>, to which also the
-      <firstterm>postgres</firstterm> process belongs. Their duties are
-      handling of central, common database activities like file access,
-      vacuum, <glossterm linkend="glossary-checkpoint">checkpoints</glossterm>,
-      replication, and more. The mentioned <firstterm>Backend processes</firstterm>
-      delegate those actions to the <firstterm>instance</firstterm>.
+      linkend="glossary-instance">Instance</glossterm>, to which also
+      the Postmaster process belongs. Their duties are handling of
+      central, common database activities like file access, transaction
+      handling, vacuum, checkpoints, replication, and more. The mentioned
+      Backend processes delegate those actions to the instance.
      </para>
     </listitem>
 
@@ -127,18 +124,6 @@
     file name) on the database server machine.
    </para>
 
-   <para>
-    The <productname>PostgreSQL</productname> server can handle
-    multiple concurrent connections from clients.  To achieve this it
-    starts (<quote>forks</quote>) a new process for each connection.
-    From that point on, the client and the new server process
-    communicate without intervention by the original
-    <filename>postgres</filename> process.  Thus, the
-    supervisor server process is always running, waiting for
-    client connections, whereas client and associated server processes
-    come and go.  (All of this is of course invisible to the user.  We
-    only mention it here for completeness.)
-   </para>
   </sect1>
 
 
