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. 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. 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
