Re: BUG #3898: Postgres autovacuum not respecting pg_autovacuum.enabled = false
От | Simon Riggs |
---|---|
Тема | Re: BUG #3898: Postgres autovacuum not respecting pg_autovacuum.enabled = false |
Дата | |
Msg-id | 1201166357.4257.125.camel@ebony.site обсуждение исходный текст |
Ответ на | Re: BUG #3898: Postgres autovacuum not respecting pg_autovacuum.enabled = false (Alvaro Herrera <alvherre@commandprompt.com>) |
Список | pgsql-bugs |
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". -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com
В списке pgsql-bugs по дате отправления: