Re: WAL Rate Limiting - Mailing list pgsql-hackers

From Tom Lane
Subject Re: WAL Rate Limiting
Date
Msg-id 28289.1389889168@sss.pgh.pa.us
Whole thread Raw
In response to Re: WAL Rate Limiting  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: WAL Rate Limiting  (Andres Freund <andres@2ndquadrant.com>)
Re: WAL Rate Limiting  (Jeff Janes <jeff.janes@gmail.com>)
List pgsql-hackers
Andres Freund <andres@2ndquadrant.com> writes:
> On 2014-01-16 17:47:51 +0200, Heikki Linnakangas wrote:
>> In suitable safe places, check if you've written too much WAL, and sleep if
>> so.

> That'd be most places doing XLogInsert() if you want to be
> consistent.

See my other response.  There's no need for "consistency", only to be sure
that code paths that might generate a *lot* of WAL include such checks.
We've gotten along fine without any formal methodology for where to put
CHECK_FOR_INTERRUPTS() or vacuum_delay_point() calls, and this seems like
just more of the same.

> I think the usecases that would want this for DML probably also wan this
> to work for unlogged, temp tables.

Huh?  Unlogged tables generate *zero* WAL, by definition.

If your point is that WAL creation isn't a particularly good resource
consumption metric, that's an argument worth considering, but it seems
quite orthogonal to whether we can implement such throttling reasonably.
And in any case, you didn't provide such an argument.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Why conf.d should be default, and auto.conf and recovery.conf should be in it
Next
From: Andres Freund
Date:
Subject: Re: Why conf.d should be default, and auto.conf and recovery.conf should be in it