On Wed, Oct 1, 2014 at 11:44 AM, Alvaro Herrera
wrote:
> Robert Haas wrote:
>> This kind of seems like throwing darts at the wall. It could be
>> better if we are right to skip the database already being vacuumed for
>> wraparound, or worse if we're not.
>
> Well, it only skips the DB for half th
Robert Haas wrote:
> This kind of seems like throwing darts at the wall. It could be
> better if we are right to skip the database already being vacuumed for
> wraparound, or worse if we're not.
Well, it only skips the DB for half the naptime interval, so that other
databases have a chance to be
On Tue, Sep 30, 2014 at 5:59 PM, Alvaro Herrera
wrote:
> Jeff Janes wrote:
>> > I think that instead of
>> > trying to get a single target database in that foreach loop, we could
>> > try to build a prioritized list (in-wraparound-danger first, then
>> > in-multixid-wraparound danger, then the one
Alvaro Herrera wrote:
> The attached patch implements that. I only tested it on HEAD, but
> AFAICS it applies cleanly to 9.4 and 9.3; fairly sure it won't apply to
> 9.2. Given the lack of complaints, I'm unsure about backpatching
> further back than 9.3 anyway.
FWIW my intention is to make sur
On Mon, Jun 23, 2014 at 7:19 PM, Tom Lane wrote:
> Jeff Janes writes:
>> I didn't add this patch to the commitfest, because it was just a point
>> for discussion and not actually proposed for application. But It
>> doesn't seem to have provoked much discussion either.
>
>> Should I go add this t
Jeff Janes writes:
> I didn't add this patch to the commitfest, because it was just a point
> for discussion and not actually proposed for application. But It
> doesn't seem to have provoked much discussion either.
> Should I go add this to the next commitfest?
> I do see it listed as a resolve
On Thu, May 15, 2014 at 4:06 PM, Jeff Janes wrote:
> On Thu, May 15, 2014 at 12:55 PM, Alvaro Herrera
> wrote:
>>
>> Jeff Janes wrote:
>>
>> > If you have a database with a large table in it that has just passed
>> > autovacuum_freeze_max_age, all future workers will be funnelled into
>> > that
>
Jeff Janes wrote:
> If you have a database with a large table in it that has just passed
> autovacuum_freeze_max_age, all future workers will be funnelled into that
> database until the wrap-around completes. But only one of those workers
> can actually vacuum the one table which is holding back
In testing 9.4 with some long running tests, I noticed that autovacuum
launcher/worker sometimes goes a bit nuts. It vacuums the same database
repeatedly without respect to the nap time.
As far as I can tell, the behavior is the same in older versions, but I
haven't tested that.
This is my under
