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

Commitd6657d2

Browse files
committed
Treat negative values of recovery_min_apply_delay as having no effect.
At one point in the development of this feature, it was claimed thatallowing negative values would be useful to compensate for timezonedifferences between master and slave servers. That was based on a mistakenassumption that commit timestamps are recorded in local time; but of coursethey're in UTC. Nor is a negative apply delay likely to be a sane way ofcoping with server clock skew. However, the committed patch still treatednegative delays as doing something, and the timezone misapprehensionsurvived in the user documentation as well.If recovery_min_apply_delay were a proper GUC we'd just set the minimumallowed value to be zero; but for the moment it seems better to treatnegative settings as if they were zero.In passing do some extra wordsmithing on the parameter's documentation,including correcting a second misstatement that the parameter affectsprocessing of Restore Point records.Issue noted by Michael Paquier, who also provided the code patch; docchanges by me. Back-patch to 9.4 where the feature was introduced.
1 parentf9769c7 commitd6657d2

File tree

2 files changed

+12
-13
lines changed

2 files changed

+12
-13
lines changed

‎doc/src/sgml/recovery-config.sgml

Lines changed: 11 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -458,9 +458,9 @@ restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"' # Windows
458458
<para>
459459
By default, a standby server restores WAL records from the
460460
primary as soon as possible. It may be useful to have a time-delayed
461-
copy of the data, offeringvarious options to correct data loss errors.
461+
copy of the data, offeringopportunities to correct data loss errors.
462462
This parameter allows you to delay recovery by a fixed period of time,
463-
specified in milliseconds if no unit is specified. For example, if
463+
measured in milliseconds if no unit is specified. For example, if
464464
you set this parameter to <literal>5min</literal>, the standby will
465465
replay each transaction commit only when the system time on the standby
466466
is at least five minutes past the commit time reported by the master.
@@ -469,27 +469,26 @@ restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"' # Windows
469469
It is possible that the replication delay between servers exceeds the
470470
value of this parameter, in which case no delay is added.
471471
Note that the delay is calculated between the WAL timestamp as written
472-
on master and the time on thecurrentstandby. Delays
473-
in transferbecause ofnetworks or cascading replication configurations
472+
on master and thecurrenttime on the standby. Delays in transfer
473+
because ofnetwork lag or cascading replication configurations
474474
may reduce the actual wait time significantly. If the system
475475
clocks on master and standby are not synchronized, this may lead to
476476
recovery applying records earlier than expected; but that is not a
477-
major issue because useful settings of the parameter are much larger
478-
than typical time deviations between servers. Be careful to allow for
479-
different timezone settings on master and standby.
477+
major issue because useful settings of this parameter are much larger
478+
than typical time deviations between servers.
480479
</para>
481480
<para>
482-
The delay occurs only on WAL records forCOMMIT and Restore Points.
483-
Other recordsmay bereplayedearlier than the specified delay, which
484-
is notan issue for MVCCthough it may potentially increase the number
485-
of recovery conflicts generated.
481+
The delay occurs only on WAL records fortransaction commits.
482+
Other recordsarereplayedas quickly as possible, which
483+
is nota problem because MVCCvisibility rules ensure their effects
484+
are not visible until the corresponding commit record is applied.
486485
</para>
487486
<para>
488487
The delay occurs until the standby is promoted or triggered. After that
489488
the standby will end recovery without further waiting.
490489
</para>
491490
<para>
492-
This parameter is intended for use with streaming replication deployments,
491+
This parameter is intended for use with streaming replication deployments;
493492
however, if the parameter is specified it will be honored in all cases.
494493
Synchronous replication is not affected by this setting because there is
495494
not yet any setting to request synchronous apply of transaction commits.

‎src/backend/access/transam/xlog.c

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -5430,7 +5430,7 @@ recoveryApplyDelay(XLogReaderState *record)
54305430
intmicrosecs;
54315431

54325432
/* nothing to do if no delay configured */
5433-
if (recovery_min_apply_delay==0)
5433+
if (recovery_min_apply_delay<=0)
54345434
return false;
54355435

54365436
/*

0 commit comments

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