rdelaage
/
postgresql
mirror of https://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Remove warning about num_sync being too large in synchronous_standby_names. 

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 Specifies whether transaction commit will wait for WAL records
to be written to disk before the command returns a <quote>success</> to be written to disk before the command returns a <quote>success</>
indication to the client. Valid values are <literal>on</>, 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 and <literal>off</>. The default, and safe, setting
is <literal>on</>. When <literal>off</>, there can be a delay between is <literal>on</>. When <literal>off</>, there can be a delay between
when success is reported to the client and when the transaction is 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">. discussion see <xref linkend="wal-async-commit">.
</para> </para>
<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 parameter also controls whether or not transaction commits will wait
for the transaction's WAL records to be replicated to the standby for their WAL records to be replicated to the standby server(s).
server. When set to <literal>on</>, commits will wait until replies
When set to <literal>on</>, commits will wait until a reply from the current synchronous standby(s) indicate they have received
from the current synchronous standby indicates it has received
the commit record of the transaction and flushed it to disk. This the commit record of the transaction and flushed it to disk. This
ensures the transaction will not be lost unless both primary and ensures the transaction will not be lost unless both the primary and
standby suffer corruption of their database storage. all synchronous standbys suffer corruption of their database storage.
When set to <literal>remote_apply</>, commits will wait until a reply When set to <literal>remote_apply</>, commits will wait until replies
from the current synchronous standby indicates it has received the from the current synchronous standby(s) indicate they have received the
commit record of the transaction and applied it, so that it has become commit record of the transaction and applied it, so that it has become
visible to queries. visible to queries on the standby(s).
When set to <literal>remote_write</>, commits will wait When set to <literal>remote_write</>, commits will wait until replies
until a reply from the current synchronous standby indicates it has from the current synchronous standby(s) indicate they have
received the commit record of the transaction and written it out to received the commit record of the transaction and written it out to
the standby's operating system, but the data has not necessarily their operating system. This setting is sufficient to
reached stable storage on the standby. This setting is sufficient to ensure data preservation even if a standby instance of
ensure data preservation even if the standby instance of
<productname>PostgreSQL</> were to crash, but not if the standby <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>
<para> <para>
When synchronous If <varname>synchronous_standby_names</> is empty, the settings
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
<literal>on</>, <literal>remote_apply</>, <literal>remote_write</> <literal>on</>, <literal>remote_apply</>, <literal>remote_write</>
and <literal>local</> all provide the same synchronization level: and <literal>local</> all provide the same synchronization level:
transaction commits only wait for local flush to disk. 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; 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 */ /* GUC extra value must be malloc'd, not palloc'd */
pconf = (SyncRepConfigData *) pconf = (SyncRepConfigData *)
malloc(syncrep_parse_result->config_size); malloc(syncrep_parse_result->config_size);