</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>
<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>