Re: Per table autovacuum vacuum cost limit behaviour strange

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Per table autovacuum vacuum cost limit behaviour strange
Date: 2014-10-02 15:37:05
Message-ID: 20141002153705.GY5311@eldon.alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Stephen Frost wrote:
> * Robert Haas (robertmhaas(at)gmail(dot)com) wrote:

> > I agree with both of those arguments. I have run into very few
> > customers who have used the autovacuum settings to customize behavior
> > for particular tables, and anyone who hasn't should see no change
> > (right?), so my guess is that the practical impact of the change will
> > be pretty limited. On the other hand, it's a clear behavior change.
> > Someone could have set the per-table limit to something enormous and
> > never suffered from that setting because it has basically no effect as
> > things stand right now today; and that person might get an unpleasant
> > surprise when they update.
> >
> > I would at least back-patch it to 9.4. I could go either way on
> > whether to back-patch into older branches. I lean mildly in favor of
> > it at the moment, but with considerable trepidation.
>
> I'm fine with putting it into 9.4. I'm not sure that I see the value in
> changing the back-branches and then having to deal with the "well, if
> you're on 9.3.5 then X, but if you're on 9.3.6 then Y" or having to
> figure out how to deal with the documentation for this.

Well, the value obviously is that we would fix the bug that Mark
Kirkwood reported that started this thread.

Basically, if you are on 9.3.5 or earlier any per-table options for
autovacuum cost delay will misbehave (meaning: any such table will be
processed with settings flattened according to balancing of the standard
options, _not_ the configured ones). If you are on 9.3.6 or newer they
will behave as described in the docs.

> Has there been any thought as to what pg_upgrade should do..?

Yes, I'm thinking there's nothing it should do.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Banck 2014-10-02 16:00:57 Re: Log notice that checkpoint is to be written on shutdown
Previous Message Robert Haas 2014-10-02 15:35:32 Re: Inefficient barriers on solaris with sun cc