From 503d963ce05654de14dd82fd53dcc99fdefa2b0c Mon Sep 17 00:00:00 2001 From: shinguz Date: Thu, 6 Aug 2026 10:06:05 +0200 Subject: [PATCH] some references on variables and functions added --- doc/src/sgml/func/func-admin.sgml | 6 ++-- doc/src/sgml/high-availability.sgml | 43 +++++++++++++++-------------- 2 files changed, 25 insertions(+), 24 deletions(-) diff --git a/doc/src/sgml/func/func-admin.sgml b/doc/src/sgml/func/func-admin.sgml index 0eae1c1f616..a14497e32de 100644 --- a/doc/src/sgml/func/func-admin.sgml +++ b/doc/src/sgml/func/func-admin.sgml @@ -403,7 +403,7 @@ LOG: Grand total: 1651920 bytes in 201 blocks; 622360 free (88 chunks); 1029560 - + pg_backup_start @@ -430,7 +430,7 @@ LOG: Grand total: 1651920 bytes in 201 blocks; 622360 free (88 chunks); 1029560 - + pg_backup_stop @@ -491,7 +491,7 @@ LOG: Grand total: 1651920 bytes in 201 blocks; 622360 free (88 chunks); 1029560 - + pg_switch_wal diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml index fd338ab1540..91dfe8cd13d 100644 --- a/doc/src/sgml/high-availability.sgml +++ b/doc/src/sgml/high-availability.sgml @@ -1091,7 +1091,7 @@ primary_slot_name = 'node_a_slot' standby servers. This extends that standard level of durability offered by a transaction commit. This level of protection is referred to as 2-safe replication in computer science theory, and group-1-safe - (group-safe and 1-safe) when synchronous_commit is set to + (group-safe and 1-safe) when is set to remote_write. @@ -1124,7 +1124,7 @@ primary_slot_name = 'node_a_slot' replication stream consumer that knows how to send the appropriate feedback messages. Besides the built-in physical and logical replication systems, this includes special programs such - as pg_receivewal and pg_recvlogical + as and as well as some third-party replication systems and custom programs. Check the respective documentation for details on synchronous replication support. @@ -1137,14 +1137,14 @@ primary_slot_name = 'node_a_slot' Once streaming replication has been configured, configuring synchronous replication requires only one additional configuration step: must be set to - a non-empty value. synchronous_commit must also be set to + a non-empty value. must also be set to on, but since this is the default value, typically no change is required. (See and .) This configuration will cause each commit to wait for confirmation that the standby has written the commit record to durable storage. - synchronous_commit can be set by individual + can be set by individual users, so it can be configured in the configuration file, for particular users or databases, or dynamically by applications, in order to control the durability guarantee on a per-transaction basis. @@ -1155,11 +1155,11 @@ primary_slot_name = 'node_a_slot' WAL record is then sent to the standby. The standby sends reply messages each time a new batch of WAL data is written to disk, unless wal_receiver_status_interval is set to zero on the standby. - In the case that synchronous_commit is set to + In the case that is set to remote_apply, the standby sends reply messages when the commit record is replayed, making the transaction visible. If the standby is chosen as a synchronous standby, according to the setting - of synchronous_standby_names on the primary, the reply + of on the primary, the reply messages from that standby will be considered along with those from other synchronous standbys to decide when to release transactions waiting for confirmation that the commit record has been received. These parameters @@ -1171,7 +1171,7 @@ primary_slot_name = 'node_a_slot' - Setting synchronous_commit to remote_write will + Setting to remote_write will cause each commit to wait for confirmation that the standby has received the commit record and written it out to its own operating system, but not for the data to be flushed to disk on the standby. This @@ -1185,7 +1185,7 @@ primary_slot_name = 'node_a_slot' - Setting synchronous_commit to remote_apply will + Setting to remote_apply will cause each commit to wait until the current synchronous standbys report that they have replayed the transaction, making it visible to user queries. In simple cases, this allows for load balancing with causal @@ -1211,7 +1211,7 @@ primary_slot_name = 'node_a_slot' transactions will wait until all the standby servers which are considered as synchronous confirm receipt of their data. The number of synchronous standbys that transactions must wait for replies from is specified in - synchronous_standby_names. This parameter also specifies + . This parameter also specifies a list of standby names and the method (FIRST and ANY) to choose synchronous standbys from the listed ones. @@ -1227,7 +1227,7 @@ primary_slot_name = 'node_a_slot' next-highest-priority standby. - An example of synchronous_standby_names for + An example of for a priority-based multiple synchronous standbys is: synchronous_standby_names = 'FIRST 2 (s1, s2, s3)' @@ -1248,7 +1248,7 @@ synchronous_standby_names = 'FIRST 2 (s1, s2, s3)' synchronous standbys in the list. - An example of synchronous_standby_names for + An example of for a quorum-based multiple synchronous standbys is: synchronous_standby_names = 'ANY 2 (s1, s2, s3)' @@ -1310,9 +1310,9 @@ synchronous_standby_names = 'ANY 2 (s1, s2, s3)' Planning for High Availability - synchronous_standby_names specifies the number and + specifies the number and names of synchronous standbys that transaction commits made when - synchronous_commit is set to on, + is set to on, remote_apply or remote_write will wait for responses from. Such transaction commits may never be completed if any one of the synchronous standbys should crash. @@ -1321,7 +1321,7 @@ synchronous_standby_names = 'ANY 2 (s1, s2, s3)' The best solution for high availability is to ensure you keep as many synchronous standbys as requested. This can be achieved by naming multiple - potential synchronous standbys using synchronous_standby_names. + potential synchronous standbys using . @@ -1369,7 +1369,7 @@ synchronous_standby_names = 'ANY 2 (s1, s2, s3)' If you really cannot keep as many synchronous standbys as requested then you should decrease the number of synchronous standbys that transaction commits must wait for responses from - in synchronous_standby_names (or disable it) and + in (or disable it) and reload the configuration file on the primary server. @@ -1380,9 +1380,9 @@ synchronous_standby_names = 'ANY 2 (s1, s2, s3)' If you need to re-create a standby server while transactions are - waiting, make sure that the functions pg_backup_start() - and pg_backup_stop() are run in a session with - synchronous_commit = off, otherwise those + waiting, make sure that the functions pg_backup_start() + and pg_backup_stop() are run in a session with + = off, otherwise those requests will wait forever for the standby to appear. @@ -1459,10 +1459,10 @@ postgres=# WAIT FOR LSN '0/306EE20'; to always, and the standby will call the archive command for every WAL segment it receives, whether it's by restoring from the archive or by streaming replication. The shared archive can - be handled similarly, but the archive_command or archive_library must + be handled similarly, but the or must test if the file being archived exists already, and if the existing file has identical contents. This requires more care in the - archive_command or archive_library, as it must + or , as it must be careful to not overwrite an existing file with different contents, but return success if the exactly same file is archived twice. And all that must be done free of race conditions, if two servers attempt @@ -2238,7 +2238,8 @@ HINT: You can then restart the server after making the necessary configuration WAL file control commands will not work during recovery, - e.g., pg_backup_start, pg_switch_wal etc. + e.g., pg_backup_start(), + pg_switch_wal() etc. -- 2.47.3