Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit17d5db3

Browse files
committed
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 incheck_synchronous_standby_names() is unhelpful, because it will cause thewarning 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 notgotten the word that now there can be more than one synchronous standby.
1 parent207d5a6 commit17d5db3

File tree

2 files changed

+21
-69
lines changed

2 files changed

+21
-69
lines changed

‎doc/src/sgml/config.sgml

Lines changed: 21 additions & 24 deletions
Original file line numberDiff line numberDiff line change
@@ -2220,7 +2220,7 @@ include_dir 'conf.d'
22202220
Specifies whether transaction commit will wait for WAL records
22212221
to be written to disk before the command returns a <quote>success</>
22222222
indication to the client. Valid values are <literal>on</>,
2223-
<literal>remote_write</>, <literal>remote_apply</>, <literal>local</>,
2223+
<literal>remote_apply</>, <literal>remote_write</>, <literal>local</>,
22242224
and <literal>off</>. The default, and safe, setting
22252225
is <literal>on</>. When <literal>off</>, there can be a delay between
22262226
when success is reported to the client and when the transaction is
@@ -2237,36 +2237,33 @@ include_dir 'conf.d'
22372237
discussion see <xref linkend="wal-async-commit">.
22382238
</para>
22392239
<para>
2240-
If <xref linkend="guc-synchronous-standby-names"> isset, this
2240+
If <xref linkend="guc-synchronous-standby-names"> isnon-empty, this
22412241
parameter also controls whether or not transaction commits will wait
2242-
for the transaction's WAL records to be replicated to the standby
2243-
server.
2244-
When set to <literal>on</>, commits will wait until a reply
2245-
from the current synchronous standby indicates it has received
2242+
for their WAL records to be replicated to the standby server(s).
2243+
When set to <literal>on</>, commits will wait until replies
2244+
from the current synchronous standby(s) indicate they have received
22462245
the commit record of the transaction and flushed it to disk. This
2247-
ensures the transaction will not be lost unless both primary and
2248-
standby suffer corruption of their database storage.
2249-
When set to <literal>remote_apply</>, commits will wait untila reply
2250-
from the current synchronous standby indicates it has received the
2246+
ensures the transaction will not be lost unless boththeprimary and
2247+
all synchronous standbys suffer corruption of their database storage.
2248+
When set to <literal>remote_apply</>, commits will wait untilreplies
2249+
from the current synchronous standby(s) indicate they have received the
22512250
commit record of the transaction and applied it, so that it has become
2252-
visible to queries.
2253-
When set to <literal>remote_write</>, commits will wait
2254-
until a replyfrom the current synchronous standby indicates it has
2251+
visible to queries on the standby(s).
2252+
When set to <literal>remote_write</>, commits will wait until replies
2253+
from the current synchronous standby(s) indicate they have
22552254
received the commit record of the transaction and written it out to
2256-
the standby's operating system, but the data has not necessarily
2257-
reached stable storage on the standby. This setting is sufficient to
2258-
ensure data preservation even if the standby instance of
2255+
their operating system. This setting is sufficient to
2256+
ensure data preservation even if a standby instance of
22592257
<productname>PostgreSQL</> were to crash, but not if the standby
2260-
suffers an operating-system-level crash.
2258+
suffers an operating-system-level crash, since the data has not
2259+
necessarily reached stable storage on the standby.
2260+
Finally, the setting <literal>local</> causes commits to wait for
2261+
local flush to disk, but not for replication. This is not usually
2262+
desirable when synchronous replication is in use, but is provided for
2263+
completeness.
22612264
</para>
22622265
<para>
2263-
When synchronous
2264-
replication is in use, it will normally be sensible either to wait
2265-
for both local flush to disk and replication of WAL records, or
2266-
to allow the transaction to commit asynchronously. However, the
2267-
setting <literal>local</> is available for transactions that
2268-
wish to wait for local flush to disk, but not synchronous replication.
2269-
If <varname>synchronous_standby_names</> is not set, the settings
2266+
If <varname>synchronous_standby_names</> is empty, the settings
22702267
<literal>on</>, <literal>remote_apply</>, <literal>remote_write</>
22712268
and <literal>local</> all provide the same synchronization level:
22722269
transaction commits only wait for local flush to disk.

‎src/backend/replication/syncrep.c

Lines changed: 0 additions & 45 deletions
Original file line numberDiff line numberDiff line change
@@ -929,51 +929,6 @@ check_synchronous_standby_names(char **newval, void **extra, GucSource source)
929929
return false;
930930
}
931931

932-
/*
933-
* Warn if num_sync exceeds the number of names of potential sync
934-
* standbys. This setting doesn't make sense in most cases because it
935-
* implies that enough number of sync standbys will not appear, which
936-
* makes transaction commits wait for sync replication infinitely.
937-
*
938-
* If there are more than one standbys having the same name and
939-
* priority, we can see enough sync standbys to complete transaction
940-
* commits. However it's not recommended to run multiple standbys with
941-
* the same priority because we cannot gain full control of the
942-
* selection of sync standbys from them.
943-
*
944-
* OTOH, that setting is OK if we understand the above problem
945-
* regarding the selection of sync standbys and intentionally specify *
946-
* to match all the standbys.
947-
*/
948-
if (syncrep_parse_result->num_sync>syncrep_parse_result->nmembers)
949-
{
950-
constchar*standby_name;
951-
inti;
952-
boolhas_asterisk= false;
953-
954-
standby_name=syncrep_parse_result->member_names;
955-
for (i=1;i <=syncrep_parse_result->nmembers;i++)
956-
{
957-
if (strcmp(standby_name,"*")==0)
958-
{
959-
has_asterisk= true;
960-
break;
961-
}
962-
standby_name+=strlen(standby_name)+1;
963-
}
964-
965-
/*
966-
* Only the postmaster warns about this inappropriate setting to
967-
* avoid cluttering the log.
968-
*/
969-
if (!has_asterisk&& !IsUnderPostmaster)
970-
ereport(WARNING,
971-
(errmsg("configured number of synchronous standbys (%d) exceeds the number of names of potential synchronous ones (%d)",
972-
syncrep_parse_result->num_sync,
973-
syncrep_parse_result->nmembers),
974-
errhint("Specify more names of potential synchronous standbys in synchronous_standby_names.")));
975-
}
976-
977932
/* GUC extra value must be malloc'd, not palloc'd */
978933
pconf= (SyncRepConfigData*)
979934
malloc(syncrep_parse_result->config_size);

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp