2011/2/5 Robert Haas <robertmhaas@gmail.com>:
> On Sat, Feb 5, 2011 at 12:54 PM, Cédric Villemain
> <cedric.villemain.debian@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