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