diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index e6a7514100..5a47ce4343 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -27084,8 +27084,8 @@ postgres=# SELECT '0/0'::pg_lsn + pd.segment_number * ps.setting::int + :offset
        </para>
        <para>
         Take a snapshot of running transactions and write it to WAL, without
-        having to wait bgwriter or checkpointer to log one. This is useful for
-        logical decoding on standby, as logical slot creation has to wait
+        having to wait for bgwriter or checkpointer to log one. This is useful
+        for logical decoding on standby, as logical slot creation has to wait
         until such a record is replayed on the standby.
        </para></entry>
       </row>
diff --git a/doc/src/sgml/logicaldecoding.sgml b/doc/src/sgml/logicaldecoding.sgml
index e61059d71e..cbd3aa804f 100644
--- a/doc/src/sgml/logicaldecoding.sgml
+++ b/doc/src/sgml/logicaldecoding.sgml
@@ -321,16 +321,18 @@ postgres=# select * from pg_logical_slot_get_changes('regression_slot', NULL, NU
      <command>VACUUM</command> from removing required rows from the system
      catalogs, <varname>hot_standby_feedback</varname> should be set on the
      standby. In spite of that, if any required rows get removed, the slot gets
-     invalidated. It's highly recommended to use a physical slot between the primary
-     and the standby. Otherwise, hot_standby_feedback 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 wal_level
-     on primary is reduced to less than 'logical'. This is done as soon as the
-     standby detects such a change in the WAL stream. It means, that for walsenders
-     that are lagging (if any), some WAL records up to the wal_level parameter change
-     on the primary won't be decoded.
+     invalidated. It's highly recommended to use a physical slot between the
+     primary and the standby. Otherwise, <varname>hot_standby_feedback</varname>
+     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>.
+     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
+     to the <varname>wal_level</varname> parameter change on the primary won't be
+     decoded.
     </para>
 
     <para>
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 0281201745..2903b67170 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -4757,7 +4757,7 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
       </para>
       <para>
        Number of uses of logical slots in this database that have been
-       canceled due to old snapshots or a too low <xref linkend="guc-wal-level"/>
+       canceled due to old snapshots or too low a <xref linkend="guc-wal-level"/>
        on the primary
       </para></entry>
      </row>