@@ -1359,8 +1359,8 @@ synchronous_standby_names = 'ANY 2 (s1, s2, s3)'
13591359
13601360 <para>
13611361 If you need to re-create a standby server while transactions are
1362- waiting, make sure that the commands pg_backup_start() and
1363- pg_backup_stop() are run in a session with
1362+ waiting, make sure that the functions <function> pg_backup_start()</function>
1363+ and <function> pg_backup_stop()</function> are run in a session with
13641364 <varname>synchronous_commit</varname> = <literal>off</literal>, otherwise those
13651365 requests will wait forever for the standby to appear.
13661366 </para>
@@ -2219,10 +2219,11 @@ HINT: You can then restart the server after making the necessary configuration
22192219 The cumulative statistics system is active during recovery. All scans,
22202220 reads, blocks, index usage, etc., will be recorded normally on the
22212221 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.
22262227 </para>
22272228
22282229 <para>
0 commit comments