@@ -802,7 +802,7 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
802
802
<row>
803
803
<entry><structfield>backend_type</structfield></entry>
804
804
<entry><type>text</type></entry>
805
- <entry>Type of current backend. Possible types are
805
+ <entry>Type of current backend. Possible types are
806
806
<literal>autovacuum launcher</>, <literal>autovacuum worker</>,
807
807
<literal>background worker</>, <literal>background writer</>,
808
808
<literal>client backend</>, <literal>checkpointer</>,
@@ -1827,7 +1827,7 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
1827
1827
the standby to catch up with the sending server assuming the current
1828
1828
rate of replay. Such a system would show similar times while new WAL is
1829
1829
being generated, but would differ when the sender becomes idle. In
1830
- particular, when the standby has caught up completely,
1830
+ particular, when the standby has caught up completely,
1831
1831
<structname>pg_stat_replication</structname> shows the time taken to
1832
1832
write, flush and replay the most recent reported WAL location rather than
1833
1833
zero as some users might expect. This is consistent with the goal of