On Thu, 2008-01-24 at 00:01 -0300, Alvaro Herrera wrote:
> IMO it's a usability bug which will be gone when we move to
> pg_class.reloptions -- you won't need to set random values for options
> you don't know what to set to.
But this is a problem in *this* release (and the last also?).
> As for documentation, this is mentioned somewhere. Perhaps not clearly
> enough? OTOH I think the real problem is that people think
> documentation can be skipped, thus they don't know the "fine print" --
> so it won't matter how non-fine we make it.
Not clear enough. I don't think Tom's suggested wording goes far enough
because not everybody understands this sufficiently to make the leap
that low settings will put you into a cycle of constant vacuuming.
We clamp autovacuum_freeze_max_age and autovacuum_freeze_min_age to
certain values, so I think we should do the same for values in the
pg_autovacuum table. i.e. force freeze_min_age and freeze_max_age to the
same min/max values as their GUC equivalents. Or at very least issue a
WARNING to the logs if a too-low value is present.
The docs should say "If you set autovacuum_freeze_age to 0 or a low
positive number this will cause the table to be constantly VACUUM
FREEZEd, which you might want, but you very probably don't".
In response to
pgsql-bugs by date
|Next:||From: Kris Jurka||Date: 2008-01-24 11:16:05|
|Subject: Re: BUG #3897: plJava dll still doesn't load|
|Previous:||From: Alvaro Herrera||Date: 2008-01-24 03:01:13|
|Subject: Re: BUG #3898: Postgres autovacuum not respectingpg_autovacuum.enabled = false|