diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index b2c5e4d5dd..575168ed23 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -2220,7 +2220,7 @@ include_dir 'conf.d' Specifies whether transaction commit will wait for WAL records to be written to disk before the command returns a success indication to the client. Valid values are on, - remote_write, remote_apply, local, + remote_apply, remote_write, local, and off. The default, and safe, setting is on. When off, there can be a delay between when success is reported to the client and when the transaction is @@ -2237,36 +2237,33 @@ include_dir 'conf.d' discussion see . - If is set, this + If is non-empty, this parameter also controls whether or not transaction commits will wait - for the transaction's WAL records to be replicated to the standby - server. - When set to on, commits will wait until a reply - from the current synchronous standby indicates it has received + for their WAL records to be replicated to the standby server(s). + When set to on, commits will wait until replies + from the current synchronous standby(s) indicate they have received the commit record of the transaction and flushed it to disk. This - ensures the transaction will not be lost unless both primary and - standby suffer corruption of their database storage. - When set to remote_apply, commits will wait until a reply - from the current synchronous standby indicates it has received the + ensures the transaction will not be lost unless both the primary and + all synchronous standbys suffer corruption of their database storage. + When set to remote_apply, commits will wait until replies + from the current synchronous standby(s) indicate they have received the commit record of the transaction and applied it, so that it has become - visible to queries. - When set to remote_write, commits will wait - until a reply from the current synchronous standby indicates it has + visible to queries on the standby(s). + When set to remote_write, commits will wait until replies + from the current synchronous standby(s) indicate they have received the commit record of the transaction and written it out to - the standby's operating system, but the data has not necessarily - reached stable storage on the standby. This setting is sufficient to - ensure data preservation even if the standby instance of + their operating system. This setting is sufficient to + ensure data preservation even if a standby instance of PostgreSQL were to crash, but not if the standby - suffers an operating-system-level crash. + suffers an operating-system-level crash, since the data has not + necessarily reached stable storage on the standby. + Finally, the setting local causes commits to wait for + local flush to disk, but not for replication. This is not usually + desirable when synchronous replication is in use, but is provided for + completeness. - When synchronous - replication is in use, it will normally be sensible either to wait - for both local flush to disk and replication of WAL records, or - to allow the transaction to commit asynchronously. However, the - setting local is available for transactions that - wish to wait for local flush to disk, but not synchronous replication. - If synchronous_standby_names is not set, the settings + If synchronous_standby_names is empty, the settings on, remote_apply, remote_write and local all provide the same synchronization level: transaction commits only wait for local flush to disk. diff --git a/src/backend/replication/syncrep.c b/src/backend/replication/syncrep.c index acdbf1e230..959ca78a1e 100644 --- a/src/backend/replication/syncrep.c +++ b/src/backend/replication/syncrep.c @@ -929,51 +929,6 @@ check_synchronous_standby_names(char **newval, void **extra, GucSource source) return false; } - /* - * Warn if num_sync exceeds the number of names of potential sync - * standbys. This setting doesn't make sense in most cases because it - * implies that enough number of sync standbys will not appear, which - * makes transaction commits wait for sync replication infinitely. - * - * If there are more than one standbys having the same name and - * priority, we can see enough sync standbys to complete transaction - * commits. However it's not recommended to run multiple standbys with - * the same priority because we cannot gain full control of the - * selection of sync standbys from them. - * - * OTOH, that setting is OK if we understand the above problem - * regarding the selection of sync standbys and intentionally specify * - * to match all the standbys. - */ - if (syncrep_parse_result->num_sync > syncrep_parse_result->nmembers) - { - const char *standby_name; - int i; - bool has_asterisk = false; - - standby_name = syncrep_parse_result->member_names; - for (i = 1; i <= syncrep_parse_result->nmembers; i++) - { - if (strcmp(standby_name, "*") == 0) - { - has_asterisk = true; - break; - } - standby_name += strlen(standby_name) + 1; - } - - /* - * Only the postmaster warns about this inappropriate setting to - * avoid cluttering the log. - */ - if (!has_asterisk && !IsUnderPostmaster) - ereport(WARNING, - (errmsg("configured number of synchronous standbys (%d) exceeds the number of names of potential synchronous ones (%d)", - syncrep_parse_result->num_sync, - syncrep_parse_result->nmembers), - errhint("Specify more names of potential synchronous standbys in synchronous_standby_names."))); - } - /* GUC extra value must be malloc'd, not palloc'd */ pconf = (SyncRepConfigData *) malloc(syncrep_parse_result->config_size);