From 87cec51d3ad1107f6f224ed7d773e70c8896e4c0 Mon Sep 17 00:00:00 2001 From: Andres Freund Date: Mon, 23 Mar 2015 16:40:10 +0100 Subject: [PATCH] Don't delay replication for less than recovery_min_apply_delay's resolution. Recovery delays are implemented by waiting on a latch, and latches take milliseconds as a parameter. The required amount of waiting was computed using microsecond resolution though and the wait loop's abort condition was checking the delay in microseconds as well. This could lead to short spurts of busy looping when the overall wait time was below a millisecond, but above 0 microseconds. Instead just formulate the wait loop's abort condition in millisecond granularity as well. Given that that's recovery_min_apply_delay resolution, it seems harmless to not wait for less than a millisecond. Backpatch to 9.4 where recovery_min_apply_delay was introduced. Discussion: 20150323141819.GH26995@alap3.anarazel.de --- src/backend/access/transam/xlog.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c index bc8363b4c7..2c6ae12b8d 100644 --- a/src/backend/access/transam/xlog.c +++ b/src/backend/access/transam/xlog.c @@ -5572,7 +5572,8 @@ recoveryApplyDelay(XLogReaderState *record) TimestampDifference(GetCurrentTimestamp(), recoveryDelayUntilTime, &secs, µsecs); - if (secs <= 0 && microsecs <= 0) + /* NB: We're ignoring waits below min_apply_delay's resolution. */ + if (secs <= 0 && microsecs / 1000 <= 0) break; elog(DEBUG2, "recovery apply delay %ld seconds, %d milliseconds",