Date: Tue, 10 Nov 2020 11:08:01 -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: <20201110160801.GA25651@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>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="3V7upXqbjpZ4EhLz"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20201110013632.GA8789@momjian.us>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk


--3V7upXqbjpZ4EhLz
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

On Mon, Nov  9, 2020 at 08:36:32PM -0500, Bruce Momjian wrote:
> On Tue, Nov  3, 2020 at 06:11:21PM +0000, Chris Wilson wrote:
> > Hi all,
> > 
> > I did some more research and found this explanation in a presentation by
> > 2ndQuadrant:
> > 
> > 
> >     When a process wants a buffer, it asks BufferAlloc for the file/block. If
> >     the block is already cached, it gets pinned and then returned. Otherwise, a
> >     new buffer must be found to hold this data. If there are no buffers free
> >     (there usually aren’t) BufferAlloc selects a buffer to evict to make space
> >     for the new one. If that page is dirty, it is written out to disk. This can
> >     cause the backend trying to allocate that buffer to block as it waits for
> >     that write I/O to complete.
> > 
> > 
> > So it seems that both reads and writes can potentially have to wait for I/O.
> > And the bgwriter reduces the risk of hitting a dirty page and needing to write
> > it before evicting.
> > 
> > So perhaps the documentation should say:
> > 
> > "There is a separate server process called the background writer, whose
> > function is to issue writes of “dirty” (new or modified) shared buffers.
> > This reduces the chances that a backend needing an empty buffer must write a
> > dirty one back to disk before evicting it."
> 
> I think this would be a step backward.  The point is to say that writes
> rarely happen in the foreground, not to explain when writes do happen. 
> With your wording, there could be other cases where writes happen in the
> foreground, and the point is they rarely happen.

I thought some more about this, and it seems the problem really is that
"wait for a write" is unclear, as you said.  This patch fixes it by
referencing "wait for such writes".

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

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


--3V7upXqbjpZ4EhLz
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..31b3ff6a20 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -2147,7 +2147,7 @@ include_dir 'conf.d'
       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.
+      user queries seldom or never need to wait for such writes to occur.
       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

--3V7upXqbjpZ4EhLz--