doc: Fix some typos and markups

Author: Ekaterina Kiryanova
Discussion: https://postgr.es/m/8a14e78f-6991-7a6e-4711-fe376635f2ad@postgrespro.ru
Backpatch-through: 14

doc/src/sgml/btree.sgml

@@ -664,7 +664,7 @@ options(<replaceable>relopts</replaceable> <type>local_relopts *</type>) returns
    certain implementation-level heuristics will fail to identify and
    delete even one garbage index tuple (in which case a page split or
    deduplication pass resolves the issue of an incoming new tuple not
-   fitting on a leaf page).  The worst case number of versions that
+   fitting on a leaf page).  The worst-case number of versions that
    any index scan must traverse (for any single logical row) is an
    important contributor to overall system responsiveness and
    throughput.  A bottom-up index deletion pass targets suspected
@@ -706,7 +706,7 @@ options(<replaceable>relopts</replaceable> <type>local_relopts *</type>) returns
    This is expected with any B-Tree index that is subject to
    significant version churn from <command>UPDATE</command>s that
    rarely or never logically modify the columns that the index covers.
-   The average and worst case number of versions per logical row can
+   The average and worst-case number of versions per logical row can
    be kept low purely through targeted incremental deletion passes.
    It's quite possible that the on-disk size of certain indexes will
    never increase by even one single page/block despite
@@ -811,7 +811,7 @@ options(<replaceable>relopts</replaceable> <type>local_relopts *</type>) returns
    constraints) to use deduplication.  This allows leaf pages to
    temporarily <quote>absorb</quote> extra version churn duplicates.
    Deduplication in unique indexes augments bottom-up index deletion,
-   especially in cases where a long-running transactions holds a
+   especially in cases where a long-running transaction holds a
    snapshot that blocks garbage collection.  The goal is to buy time
    for the bottom-up index deletion strategy to become effective
    again.  Delaying page splits until a single long-running

doc/src/sgml/catalogs.sgml

@@ -13116,7 +13116,7 @@ SELECT * FROM pg_locks pl LEFT JOIN pg_prepared_xacts ppx
    <structname>pg_stats_ext_exprs</structname> is also designed to present
    the information in a more readable format than the underlying catalogs
    &mdash; at the cost that its schema must be extended whenever the structure
-   of statistics in <link linkend="catalog-pg-statistic"><structname>pg_statistic</structname></link> changes.
+   of statistics in <structname>pg_statistic_ext</structname> changes.
   </para>
 
   <table>

doc/src/sgml/ref/alter_subscription.sgml

@@ -65,8 +65,9 @@ ALTER SUBSCRIPTION <replaceable class="parameter">name</replaceable> RENAME TO <
 
   <para>
    Commands <command>ALTER SUBSCRIPTION ... REFRESH PUBLICATION</command> and
-   <command>ALTER SUBSCRIPTION ... {SET|ADD|DROP} PUBLICATION ...</command> with refresh
-   option as true cannot be executed inside a transaction block.
+   <command>ALTER SUBSCRIPTION ... {SET|ADD|DROP} PUBLICATION ...</command>
+   with <literal>refresh</literal> option as <literal>true</literal> cannot be
+   executed inside a transaction block.
 
    These commands also cannot be executed when the subscription has
    <literal>two_phase</literal> commit enabled,

doc/src/sgml/ref/initdb.sgml

@@ -283,7 +283,7 @@ PostgreSQL documentation
         By default, <command>initdb</command> will write instructions for how
         to start the cluster at the end of its output. This option causes
         those instructions to be left out. This is primarily intended for use
-        by tools that wrap <command>initdb</command> in platform specific
+        by tools that wrap <command>initdb</command> in platform-specific
         behavior, where those instructions are likely to be incorrect.
        </para>
       </listitem>

doc/src/sgml/ref/psql-ref.sgml

@@ -1936,11 +1936,11 @@ testdb=>
         <para>
         The status of each kind of extended statistics is shown in a column
         named after its statistic kind (e.g. Ndistinct).
-        "defined" means that it was requested when creating the statistics,
-        and NULL means it wasn't requested.
-        You can use pg_stats_ext if you'd like to know whether <link linkend="sql-analyze">
-        <command>ANALYZE</command></link> was run and statistics are available to the
-        planner.
+        <literal>defined</literal> means that it was requested when creating
+        the statistics, and NULL means it wasn't requested.
+        You can use <structname>pg_stats_ext</structname> if you'd like to
+        know whether <link linkend="sql-analyze"><command>ANALYZE</command></link>
+        was run and statistics are available to the planner.
         </para>
         </listitem>
       </varlistentry>

doc/src/sgml/spgist.sgml

@@ -875,8 +875,9 @@ typedef struct spgLeafConsistentOut
 
       <para>
        Note: the <function>compress</function> method is only applied to
-       values to be stored.  The consistent methods receive query scankeys
-       unchanged, without transformation using <function>compress</function>.
+       values to be stored.  The consistent methods receive query
+       <structfield>scankeys</structfield> unchanged, without transformation
+       using <function>compress</function>.
       </para>
      </listitem>
     </varlistentry>

doc/src/sgml/test-decoding.sgml

@@ -40,8 +40,8 @@ postgres=# SELECT * FROM pg_logical_slot_get_changes('test_slot', NULL, NULL, 'i
  </para>
 
 <para>
-  We can also get the changes of the in-progress transaction and the typical
-  output, might be:
+  We can also get the changes of the in-progress transaction, and the typical
+  output might be:
 
 <programlisting>
 postgres[33712]=#* SELECT * FROM pg_logical_slot_get_changes('test_slot', NULL, NULL, 'stream-changes', '1');