]> granicus.if.org Git - postgresql/commit
Treat negative values of recovery_min_apply_delay as having no effect.
authorTom Lane <tgl@sss.pgh.pa.us>
Sat, 3 Jan 2015 18:14:03 +0000 (13:14 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Sat, 3 Jan 2015 18:14:12 +0000 (13:14 -0500)
commite7c1188756c9a57068e6be0c4cf2c448addb8b0c
treee124bfe199b525e0eb3b21f189669ee1e673aa07
parent01a162ea762a565f28188b5ee3db79b9cc90d37e
Treat negative values of recovery_min_apply_delay as having no effect.

At one point in the development of this feature, it was claimed that
allowing negative values would be useful to compensate for timezone
differences between master and slave servers.  That was based on a mistaken
assumption that commit timestamps are recorded in local time; but of course
they're in UTC.  Nor is a negative apply delay likely to be a sane way of
coping with server clock skew.  However, the committed patch still treated
negative delays as doing something, and the timezone misapprehension
survived in the user documentation as well.

If recovery_min_apply_delay were a proper GUC we'd just set the minimum
allowed value to be zero; but for the moment it seems better to treat
negative 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 affects
processing of Restore Point records.

Issue noted by Michael Paquier, who also provided the code patch; doc
changes by me.  Back-patch to 9.4 where the feature was introduced.
doc/src/sgml/recovery-config.sgml
src/backend/access/transam/xlog.c