On Wed, Nov 11, 2020 at 11:29:09AM +0000, Chris Wilson wrote:
> I still believe that my original proposed change, to "This reduces the chances
> that a backend needing an empty buffer must [itself] write a dirty one back to
> disk before evicting it" (with one extra word added), resolves the ambiguity
> and also more clearly and directly focuses it on what the bgwriter does and
> why, making it better documentation. It might be incorrect if my understanding
> is incorrect - is it?
You make some very good points. Here is an updated patch.
--
Bruce Momjian <br...@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index f043433e31..294017c86e 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -2146,9 +2146,12 @@ include_dir 'conf.d'
There is a separate server
process called the <firstterm>background writer</firstterm>, whose function
is to issue writes of <quote>dirty</quote> (new or modified) shared
- buffers. It writes shared buffers so server processes handling
- user queries seldom or never need to wait for a write to occur.
- However, the background writer does cause a net overall
+ buffers. When the percentage of dirty shared buffers is high, the
+ background writer writes some of them to the file system and marks
+ them as clean. This reduces the likelihood that server processes
+ handling user queries will be unable to find clean buffers and have
+ to write dirty buffers to the file system themselves. However,
+ the background writer does cause a net overall
increase in I/O load, because while a repeatedly-dirtied page might
otherwise be written only once per checkpoint interval, the
background writer might write it several times as it is dirtied
