@@ -1359,8 +1359,8 @@ synchronous_standby_names = 'ANY 2 (s1, s2, s3)'
1359
1359
1360
1360
<para>
1361
1361
If you need to re-create a standby server while transactions are
1362
- waiting, make sure that thecommands pg_backup_start() and
1363
- pg_backup_stop() are run in a session with
1362
+ waiting, make sure that thefunctions <function> pg_backup_start()</function>
1363
+ and <function> pg_backup_stop()</function> are run in a session with
1364
1364
<varname>synchronous_commit</varname> = <literal>off</literal>, otherwise those
1365
1365
requests will wait forever for the standby to appear.
1366
1366
</para>
@@ -2219,10 +2219,11 @@ HINT: You can then restart the server after making the necessary configuration
2219
2219
The cumulative statistics system is active during recovery. All scans,
2220
2220
reads, blocks, index usage, etc., will be recorded normally on the
2221
2221
standby. However, WAL replay will not increment relation and database
2222
- specific counters. I.e. replay will not increment pg_stat_all_tables
2223
- columns (like n_tup_ins), nor will reads or writes performed by the
2224
- startup process be tracked in the pg_statio views, nor will associated
2225
- pg_stat_database columns be incremented.
2222
+ specific counters. I.e. replay will not increment
2223
+ <structname>pg_stat_all_tables</structname> columns (like <structfield>n_tup_ins</structfield>),
2224
+ nor will reads or writes performed by the startup process be tracked in the
2225
+ <structname>pg_statio_</structname> views, nor will associated
2226
+ <structname>pg_stat_database</structname> columns be incremented.
2226
2227
</para>
2227
2228
2228
2229
<para>