database/postgres
database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-04-20 00:42:27 +03:00
Code

Remove warning about num_sync being too large in synchronous_standby_names.

Browse Source 
If we're not going to reject such setups entirely, throwing a WARNING in
check_synchronous_standby_names() is unhelpful, because it will cause the
warning to be logged again every time the postmaster receives SIGHUP.
Per discussion, just remove the warning.

In passing, improve the documentation for synchronous_commit, which had not
gotten the word that now there can be more than one synchronous standby.
This commit is contained in:
Tom Lane 2016-04-30 10:54:45 -04:00
parent 207d5a656e
commit 17d5db352c
2 changed files with 21 additions and 69 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

45
doc/src/sgml/config.sgml
View File

@ -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 <quote>success</>
indication to the client. Valid values are <literal>on</>,
<literal>remote_write</>, <literal>remote_apply</>, <literal>local</>,
<literal>remote_apply</>, <literal>remote_write</>, <literal>local</>,
and <literal>off</>. The default, and safe, setting
is <literal>on</>. When <literal>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 <xref linkend="wal-async-commit">.
</para>
<para>
If <xref linkend="guc-synchronous-standby-names"> is set, this
If <xref linkend="guc-synchronous-standby-names"> 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 <literal>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 <literal>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 <literal>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 <literal>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 <literal>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 <literal>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
<productname>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 <literal>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.
</para>
<para>
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 <literal>local</> is available for transactions that
wish to wait for local flush to disk, but not synchronous replication.
If <varname>synchronous_standby_names</> is not set, the settings
If <varname>synchronous_standby_names</> is empty, the settings
<literal>on</>, <literal>remote_apply</>, <literal>remote_write</>
and <literal>local</> all provide the same synchronization level:
transaction commits only wait for local flush to disk.

45
src/backend/replication/syncrep.c
View File

@ -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);