On 2016-03-10 17:33:33 -0500, Robert Haas wrote:
> On Thu, Mar 10, 2016 at 5:24 PM, Andres Freund <and...@anarazel.de> wrote:
> > On 2016-02-21 09:49:53 +0530, Robert Haas wrote:
> >> I think there might be a semantic distinction between these two terms.
> >> Doesn't writeback mean writing pages to disk, and flushing mean making
> >> sure that they are durably on disk?  So for example when the Linux
> >> kernel thinks there is too much dirty data, it initiates writeback,
> >> not a flush; on the other hand, at transaction commit, we initiate a
> >> flush, not writeback.
> >
> > I don't think terminology is sufficiently clear to make such a
> > distinction. Take e.g. our FlushBuffer()...
> Well then we should clarify it!

Trying that as we speak, err, write. How about:
         Whenever more than <varname>bgwriter_flush_after</varname> bytes have
         been written by the bgwriter, attempt to force the OS to issue these
         writes to the underlying storage.  Doing so will limit the amount of
         dirty data in the kernel's page cache, reducing the likelihood of
         stalls when an fsync is issued at the end of a checkpoint, or when
         the OS writes data back  in larger batches in the background.  Often
         that will result in greatly reduced transaction latency, but there
         also are some cases, especially with workloads that are bigger than
         <xref linkend="guc-shared-buffers">, but smaller than the OS's page
         cache, where performance might degrade.  This setting may have no
         effect on some platforms.  <literal>0</literal> disables controlled
         writeback. The default is <literal>256Kb</> on Linux, <literal>0</>
         otherwise. This parameter can only be set in the
         <filename>postgresql.conf</> file or on the server command line.

(plus adjustments for the other gucs)

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to