2011/2/5 Robert Haas <robertmh...@gmail.com>: > On Sat, Feb 5, 2011 at 12:54 PM, Cédric Villemain > <cedric.villemain.deb...@gmail.com> wrote: >> what do you implement exactly ? >> * The original request from Josh to get LOG when autovac can not run >> because of locks >> * VACOPT_NOWAIT, what is it ? > > What the patch implements is: > > If autovacuum can't get the table lock immediately, it skips the > table. This leaves the table still appearing to need autovacuuming, > so autovacuum will keep retrying (every 1 minute, or whatever you have > autovacuum_naptime set to) until it gets the lock. This seems clearly > better than the historical behavior of blocking on the lock, which can > potentially keep other tables in the database from getting vacuumed.
great :) > > In the case where a table is skipped for this reason, we log a message > at log level LOG. The version of the patch I posted does that > unconditionally, but my intention was to change it before commit so > that it only logs the message if log_autovacuum_min_duration is > something other than -1. yes looks better, I also note that someone suggest to not add a GUC for that. I am unsure about that, and adding a parameter for that does not hurt me at all: reducing number of parameters for memory/performance/... is fine (well, it is very good when we can), but to improve the log output I think it is ok to add more without much trouble. > > Regular vacuum behaves as before - it waits for each table lock > individually. We could expose a NOWAIT option at the SQL level as > well, so that someone could do VACOPT (NOWAIT), if that's something > people want. Might be useful, yes. -- Cédric Villemain 2ndQuadrant http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
