Stephen Frost wrote:
> * Robert Haas (robertmhaas@gmail.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