Re: Autovacuum launcher doesn't notice death of postmaster immediately
Decibel! <decibel@decibel.org>
From: "Jim C. Nasby" <decibel@decibel.org>
To: Andrew Hammond <andrew.george.hammond@gmail.com>
Cc: Alvaro Herrera <alvherre@commandprompt.com>, Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgresql.org
Date: 2007-06-08T21:47:46Z
Lists: pgsql-hackers
On Thu, Jun 07, 2007 at 12:13:09PM -0700, Andrew Hammond wrote: > On 6/7/07, Jim C. Nasby <decibel@decibel.org> wrote: > >On Mon, Jun 04, 2007 at 11:04:26AM -0400, Alvaro Herrera wrote: > >> The launcher is set up to wake up in autovacuum_naptime seconds at most. > >> So if the user configures a ridiculuos time (for example 86400 seconds, > >> which I've seen) then the launcher would not detect the postmaster death > > Is there some threshold after which we should have PostgreSQL emit a > warning to the effect of "autovacuum_naptime is very large. Are you > sure you know what you're doing?" > > >Yeah, I've seen people set that up with the intention of "now autovacuum > >will only run during our slow time!". I'm thinking it'd be worth > >mentioning in the docs that this won't work, and instead suggesting that > >they run vacuumdb -a or equivalent at that time instead. Thoughts? > > Hmmm... it seems to me that points new users towards not using > autovacuum, which doesn't seem like the best idea. I think it'd be I think we could easily word it so that it's clear that just letting autovacuum do it's thing is preferred. > better to say that setting the naptime really high is a Bad Idea. > Instead, if they want to shift maintenances to "off hours" they should > consider using a cron job that bonks around the > pg_autovacuum.vac_base_thresh or vac_scale_factor values for tables > they don't want vacuumed during "operational hours" (set them really > high at the start of operational hours, then to normal during off > hours). Tweaking the enable column would work too, but they presumably > don't want to disable ANALYZE, although it's entirely likely that new > users don't know what ANALYZE does, in which case they _really_ don't > want to disable it. That sounds like a rather ugly solution, and one that would be hard to implement; not something to be putting in the docs. -- Jim Nasby decibel@decibel.org EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)