doc: Fix some grammar and inconsistent tags

michaelpq · michaelpq · commit 40ebc41576e8 · 2023-10-23T09:58:55.000+09:00
Author: Ekaterina Kiryanova, Elena Indrupskaya, Oleg Sibiryakov, Maxim Yablokov Discussion: https://postgr.es/m/4c2a430b-32e2-44e2-aeca-03b7db6824e4@postgrespro.ru
diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml
@@ -7943,7 +7943,8 @@ SCRAM-SHA-256$<replaceable>&lt;iteration count&gt;</replaceable>:<replaceable>&l
        disk and apply at once after the transaction is committed on the
        publisher and received by the subscriber,
        <literal>p</literal> = apply changes directly using a parallel apply
-       worker if available (same as 't' if no worker is available)
+       worker if available (same as <literal>t</literal> if no worker is
+       available)
       </para></entry>
      </row>
 
diff --git a/doc/src/sgml/custom-rmgr.sgml b/doc/src/sgml/custom-rmgr.sgml
@@ -96,8 +96,8 @@ extern void RegisterCustomRmgr(RmgrId rmid, const RmgrData *rmgr);
  </para>
  <note>
    <para>
-    The extension must remain in shared_preload_libraries as long as any
-    custom WAL records may exist in the system. Otherwise
+    The extension must remain in <varname>shared_preload_libraries</varname>
+    as long as any custom WAL records may exist in the system. Otherwise
     <productname>PostgreSQL</productname> will not be able to apply or decode
     the custom WAL records, which may prevent the server from starting.
    </para>
diff --git a/doc/src/sgml/ecpg.sgml b/doc/src/sgml/ecpg.sgml
@@ -1506,9 +1506,9 @@ EXEC SQL TYPE serial_t IS long;
      </para>
 
      <para>
-      Any word you declare as a typedef cannot be used as an SQL keyword
-      in <literal>EXEC SQL</literal> commands later in the same program.
-      For example, this won't work:
+      Any word you declare as a <literal>typedef</literal> cannot be used as
+      an SQL keyword in <literal>EXEC SQL</literal> commands later in the same
+      program. For example, this won't work:
 <programlisting>
 EXEC SQL BEGIN DECLARE SECTION;
     typedef int start;
diff --git a/doc/src/sgml/installation.sgml b/doc/src/sgml/installation.sgml
@@ -2743,8 +2743,8 @@ ninja install
        <para>
         The default backend Meson uses is ninja and that should suffice for
         most use cases.  However, if you'd like to fully integrate with Visual
-        Studio, you can set the <option>BACKEND</option> to
-        <command>vs</command>.
+        Studio, you can set the <replaceable>BACKEND</replaceable> to
+        <literal>vs</literal>.
        </para>
       </listitem>
      </varlistentry>
diff --git a/doc/src/sgml/logicaldecoding.sgml b/doc/src/sgml/logicaldecoding.sgml
@@ -326,11 +326,12 @@ postgres=# select * from pg_logical_slot_get_changes('regression_slot', NULL, NU
      will work but only while the connection is alive (for example a node
      restart would break it). Then, the primary may delete system catalog rows
      that could be needed by the logical decoding on the standby (as it does
-     not know about the catalog_xmin on the standby). Existing logical slots
-     on standby also get invalidated if <varname>wal_level</varname> on the
-     primary is reduced to less than <literal>logical</literal>.
+     not know about the <literal>catalog_xmin</literal> on the standby).
+     Existing logical slots on standby also get invalidated if
+     <varname>wal_level</varname> on the primary is reduced to less than
+     <literal>logical</literal>.
      This is done as soon as the standby detects such a change in the WAL stream.
-     It means that, for walsenders which are lagging (if any), some WAL records up
+     It means that, for walsenders that are lagging (if any), some WAL records up
      to the <varname>wal_level</varname> parameter change on the primary won't be
      decoded.
     </para>
diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
@@ -2437,11 +2437,12 @@ psql "dbname=postgres replication=database" -c "IDENTIFY_SYSTEM;"
            <term>Int32</term>
            <listitem>
             <para>
-             The standby's current global xmin, excluding the catalog_xmin from any
-             replication slots. If both this value and the following
-             catalog_xmin are 0 this is treated as a notification that hot standby
-             feedback will no longer be sent on this connection. Later non-zero
-             messages may reinitiate the feedback mechanism.
+             The standby's current global <literal>xmin</literal>, excluding the
+             <literal>catalog_xmin</literal> from any replication slots. If both
+             this value and the following <literal>catalog_xmin</literal>
+             are 0, this is treated as a notification that hot standby feedback
+             will no longer be sent on this connection. Later non-zero messages
+             may reinitiate the feedback mechanism.
             </para>
            </listitem>
           </varlistentry>
@@ -2450,7 +2451,7 @@ psql "dbname=postgres replication=database" -c "IDENTIFY_SYSTEM;"
            <term>Int32</term>
            <listitem>
             <para>
-             The epoch of the global xmin xid on the standby.
+             The epoch of the global <literal>xmin</literal> xid on the standby.
             </para>
            </listitem>
           </varlistentry>
@@ -2459,8 +2460,9 @@ psql "dbname=postgres replication=database" -c "IDENTIFY_SYSTEM;"
            <term>Int32</term>
            <listitem>
             <para>
-             The lowest catalog_xmin of any replication slots on the standby. Set to 0
-             if no catalog_xmin exists on the standby or if hot standby feedback is being
+             The lowest <literal>catalog_xmin</literal> of any replication
+             slots on the standby. Set to 0 if no <literal>catalog_xmin</literal>
+             exists on the standby or if hot standby feedback is being
              disabled.
             </para>
            </listitem>
@@ -2470,7 +2472,7 @@ psql "dbname=postgres replication=database" -c "IDENTIFY_SYSTEM;"
            <term>Int32</term>
            <listitem>
             <para>
-             The epoch of the catalog_xmin xid on the standby.
+             The epoch of the <literal>catalog_xmin</literal> xid on the standby.
             </para>
            </listitem>
           </varlistentry>
diff --git a/doc/src/sgml/xact.sgml b/doc/src/sgml/xact.sgml
@@ -70,7 +70,7 @@
   </para>
 
   <para>
-   In addition to <literal>vxid</literal> and <type>xid</type>,
+   In addition to <literal>vxid</literal> and <literal>xid</literal>,
    prepared transactions are also assigned Global Transaction
    Identifiers (<acronym>GID</acronym>). GIDs are string literals up
    to 200 bytes long, which must be unique amongst other currently
@@ -121,7 +121,7 @@
   <para>
    Subtransactions can be started explicitly using the
    <command>SAVEPOINT</command> command, but can also be started in
-   other ways, such as PL/pgSQL's <command>EXCEPTION</command> clause.
+   other ways, such as PL/pgSQL's <literal>EXCEPTION</literal> clause.
    PL/Python and PL/TCL also support explicit subtransactions.
    Subtransactions can also be started from other subtransactions.
    The top-level transaction and its child subtransactions form a
