Re: We need to log aborted autovacuums

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