From 1b41ff8743b166103fa9d5d303f3e1ffacf36dbf Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Mart=C3=ADn=20Marqu=C3=A9s?= Date: Fri, 13 Apr 2018 09:44:43 -0300 Subject: [PATCH 2/2] In the past there were many systems which which had an effective resolution time of 10 milliseconds. That's not entirely true any more, yet there are still *some* systems that still have that minimum resolution for time. Suggest changing *many* for *some* to comply with modern times. --- doc/src/sgml/config.sgml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index 38e4766522..55f64299ad 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -1788,7 +1788,7 @@ include_dir 'conf.d' when the cost limit has been exceeded. The default value is zero, which disables the cost-based vacuum delay feature. Positive values enable cost-based vacuuming. - Note that on many systems, the effective resolution + Note that on some systems, the effective resolution of sleep delays is 10 milliseconds; setting vacuum_cost_delay to a value that is not a multiple of 10 might have the same results as setting it @@ -1941,7 +1941,7 @@ include_dir 'conf.d' milliseconds, and repeats. When there are no dirty buffers in the buffer pool, though, it goes into a longer sleep regardless of bgwriter_delay. The default value is 200 - milliseconds (200ms). Note that on many systems, the + milliseconds (200ms). Note that on some systems, the effective resolution of sleep delays is 10 milliseconds; setting bgwriter_delay to a value that is not a multiple of 10 might have the same results as setting it to the next higher multiple -- 2.13.6