Date: Thu, 12 Nov 2020 11:54:12 -0500
From: Bruce Momjian <bruce@momjian.us>
To: Chris Wilson <chris+google@qwirx.com>
Cc: Thomas Munro <thomas.munro@gmail.com>,
	Pg Docs <pgsql-docs@lists.postgresql.org>
Subject: Re: What does "[backends] should seldom or never need to wait for a
 write to occur" mean?
Message-ID: <20201112165412.GC25584@momjian.us>
References: <160399562040.7809.7335281028960123489@wrigleys.postgresql.org>
 <CA+hUKGJG-4huRapjPL7kBXAd+iBW5i09WKgWOFF6E31z_aHkmQ@mail.gmail.com>
 <CAOg7f8272Om2sEM8H0u8u9weVX6NTJNrZqv_FqaRBXmBEQY9aQ@mail.gmail.com>
 <CAOg7f80WL7cR1TgXXCzzXYcNtfjgAkkc+zXr9T9tshy8jBSZLw@mail.gmail.com>
 <20201110013632.GA8789@momjian.us>
 <20201110160801.GA25651@momjian.us>
 <CAOg7f80w3u2U8Jqrh=CbAYB4V07x=X88zrbPVuCCgFqcj88mJw@mail.gmail.com>
 <20201111232417.GH25840@momjian.us>
 <CAOg7f83vo1+Y3DMpu7317zgBwRZ2ZRow7VdphO7znm4AG=HJCA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="+HP7ph2BbKc20aGI"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CAOg7f83vo1+Y3DMpu7317zgBwRZ2ZRow7VdphO7znm4AG=HJCA@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk


--+HP7ph2BbKc20aGI
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

On Thu, Nov 12, 2020 at 02:40:04PM +0000, Chris Wilson wrote:
> Hi Bruce,
> 
> Thanks, yes I agree that that is much clearer. However when you say:
> 
> 
>     When the percentage of dirty shared buffers is high, the background writer
>     writes some of them to the file system...
> 
> 
> I haven't seen anything about a minimum percentage before the bgwriter kicks
> in, is that really the case? How is it configured?

Yes, I see your point.  My language was not accurate, and it didn't
match the actual background writer tuning parameters below this text. 
Here is an updated doc patch.

I agree this text should be as clear as possible because there is no way
to properly tune the background writer parameters unless we explain how
it works.   It is good you noticed this.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

  The usefulness of a cup is in its emptiness, Bruce Lee


--+HP7ph2BbKc20aGI
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment; filename="bgwriter.diff"

diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index f043433e31..8a29c90fdc 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -2146,8 +2146,11 @@ 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.
+      buffers.  When the number of non-dirty shared buffers appears to be
+      insufficient, the background writer writes some dirty buffers 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 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

--+HP7ph2BbKc20aGI--