diff --git a/doc/src/sgml/xact.sgml b/doc/src/sgml/xact.sgml
index 7ca40db961..16a23bcfe8 100644
--- a/doc/src/sgml/xact.sgml
+++ b/doc/src/sgml/xact.sgml
@@ -14,7 +14,7 @@ The word transaction is often abbreviated to "xact".
 <productname>PostgreSQL</productname> supports transactions and chained
 transactions according to the SQL Standard.
 <productname>PostgreSQL</productname> supports SAVEPOINTs through the
-implementation defined mechanism of subtransactions, which offer a superset of
+implementation-defined mechanism of subtransactions, which offer a superset of
 the required features. Prepared transactions allow PostgreSQL to implement what
 the SQL Standard refers to as encompassing transactions belonging to an external
 agent.
@@ -40,16 +40,16 @@ each request when outside of a transaction block.
 <para>
 All transactions are identified by a unique VirtualTransactionId (virtualxid or
 vxid), e.g. 4/12532, which is comprised of the BackendId (in this example, 4)
-and a sequentially assigned number unique to that backend, known as LocalXid
+and a sequentially-assigned number unique to that backend, known as LocalXid
 (in this example, 12532).
 </para>
 
 <para>
-If a transaction attempts to write to the database it will be assigned a
+If a transaction attempts to write to the database, it will first be assigned a
 TransactionId (xid), e.g. 278394. xids are assigned sequentially using a global
 counter used by all databases within a postgresql cluster (instance). This
 property is used by the transaction system to say that if one xid is earlier
-than another xid then the earlier transaction attempted to write before the
+than another xid, then the earlier transaction attempted to write before the
 later xid. However, the start and end of those two transactions are not
 constrained to occur in that sequence.
 </para>
@@ -80,6 +80,13 @@ details described here so that users have MVCC visibility with read-only
 transactions.
 </para>
 
+<para>
+In addition to vxid and xid, when a transaction is prepared it is also identified by a
+Global Transaction Identifier (GID). GIDs are string literals up to 200 bytes long,
+which must be unique amongst other currently prepared transactions.
+The mapping of GID to xid is only shown in pg_prepared_xacts.
+</para>
+
 </sect1>
 
 <sect1 id="xact-locking">
@@ -87,9 +94,9 @@ transactions.
 <title>Transactions and Locking</title>
 
 <para>
-Currently executing transactions are shown in the pg_locks view in columns
-"virtualxid" (text) and "transactionid" (xid), if an xid has been assigned.
-Read transactions will have a virtualxid but a NULL xid, while write
+Currently-executing transactions are shown in the pg_locks view in columns
+"virtualxid" (text) and "transactionid" (xid).
+Read-only transactions will have a virtualxid but a NULL xid, while read-write
 transactions will have both a virtualxid and an xid assigned.
 </para>
 
@@ -108,7 +115,7 @@ be inspected using the pgrowlocks extension.
 </para>
 
 <para>
-Row-level read locks may require the assignment of a multixact ID (mxid), which
+Row-level read locks may require the assignment of a multixact ID (mxid). Mxids
 are recorded in the pg_multixact directory.
 </para>
 
@@ -119,12 +126,22 @@ are recorded in the pg_multixact directory.
 <title>Subtransactions</title>
 
 <para>
-Subtransactions may be started from the main transaction, also known as the
-top-level transaction. Subtransactions can also be started from other
-subtransactions. As a result, the arrangement of transaction and subtransactions
-form a hierarchy or tree. Thus, each subtransaction has one parent transaction.
+Subtransactions may be started from the main transaction, allowing a large
+transaction to be broken into smaller units.
+Subtransactions may commit or abort without affecting their parent
+transaction, allowing the parent transaction to continue. This allows ERRORs
+to be handled more easily, so is a common application development pattern.
+Committed subtransactions are recorded as committed if the main transaction
+commits.  The word subtransaction is often abbreviated to "subxact".
+</para>
+
+<para>
 Over time, a transaction may have many child subtransactions.
-The word subtransaction is often abbreviated to "subxact".
+Subtransactions can also be started from other subtransactions.
+As a result, the arrangement of the main transaction and
+its child subtransactions form a hierarchy or tree, which is why we refer
+to the main transaction as the top-level transaction.
+Thus, each subtransaction has only one parent transaction.
 </para>
 
 <para>
@@ -133,24 +150,19 @@ subtransaction can be active at one time. When a subtransaction ends, the parent
 transaction becomes active again.
 </para>
 
-<para>
-Subtransactions may end via a commit or abort without affecting their parent
-transaction, allowing the parent transaction to continue.
-</para>
-
 <para>
 Subtransactions may be started explicitly by using the SAVEPOINT command, but may
 also be started in other ways, such as PL/pgSQL's EXCEPTION clause. PL/Python and
-PL/TCL also support explicit subtransactions. Working with C API, users may also
-call BeginInternalSubTransaction().
+PL/TCL also support explicit subtransactions. Working with the C API, users may
+also call BeginInternalSubTransaction().
 </para>
 
 <para>
 If a subtransaction is assigned an xid, we refer to this as a subxid. Read-only
 subtransactions are not assigned a subxid, but when a subtransaction attempts to
-write it will be assigned a subxid. We ensure that all of a subxid's parents, up
-to and including the top-level transaction are also assigned an xid. We ensure
-that a parent xid is always earlier than any of its child subxids.
+write, it will be assigned a subxid. We ensure that all of a subxid's parents, up
+to and including the top-level transaction are also assigned an xid.
+We ensure that a parent xid is always earlier than any of its child subxids.
 </para>
 
 <para>
@@ -168,7 +180,7 @@ marked as committed in the pg_xact directory.
 
 <para>
 The more subtransactions each transaction uses, the greater the overhead for
-transaction management. Up to 64 subxids are cached in shmem for each backend,
+transaction management. Up to 64 subxids are cached in shared memory for each backend;
 after that point, the overhead increases more significantly since we must look up
 the entry in pg_subtrans for each xid.
 </para>
@@ -195,8 +207,10 @@ known as two-phase commit (2PC).
 </para>
 
 <para>
-Information relating to these is stored in pg_twophase. Currently prepared
-transactions can be inspected using the pg_prepared_xacts view.
+Information relating to prepared transactions may be stored in pg_twophase, for
+prepared transactions that were prepared before the last checkpoint. In the typical
+case, shorter-lived prepared transactions are stored only in shared memory and WAL.
+Currently-prepared transactions can be inspected using the pg_prepared_xacts view.
 </para>
 
 </sect1>