Re: WAL insert delay settings - Mailing list pgsql-hackers

From Andres Freund
Subject Re: WAL insert delay settings
Date
Msg-id 20190214090605.ueywpu6dlaksy4pd@alap3.anarazel.de
Whole thread Raw
In response to Re: WAL insert delay settings  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Responses Re: WAL insert delay settings  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
List pgsql-hackers
Hi,

On 2019-02-14 10:00:38 +0100, Tomas Vondra wrote:
> On 2/13/19 4:31 PM, Stephen Frost wrote:
> > Greetings,
> > 
> > * Peter Eisentraut (peter.eisentraut@2ndquadrant.com) wrote:
> >> Bulk operations like CREATE INDEX, ALTER TABLE, or bulk loads can create
> >> a lot of WAL.  A lot of WAL at once can cause delays in replication.
> > 
> > Agreed, though I think VACUUM should certainly be included in this.
> > 
> 
> Won't these two throttling criteria interact in undesirable and/or
> unpredictable way? With the regular vacuum throttling (based on
> hit/miss/dirty) it's possible to compute rough read/write I/O limits.
> But with the additional sleeps based on amount-of-WAL, we may sleep for
> one of two reasons, so we may not reach either limit. No?

Well, it'd be max rates for either, if done right. I think we only
should start adding delays for WAL logging if we're exceeding the WAL
write rate. That's obviously more complicated than the stuff we do for
the current VACUUM throttling, but I can't see two such systems
interacting well. Also, the current logic just doesn't work well when
you consider IO actually taking time, and/or process scheduling effects
on busy systems.

Greetings,

Andres Freund


pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: WAL insert delay settings
Next
From: Tomas Vondra
Date:
Subject: Re: WAL insert delay settings