Skip site navigation (1) Skip section navigation (2)

Re: We need to log aborted autovacuums

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Cédric Villemain <cedric(dot)villemain(dot)debian(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Greg Smith <greg(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: We need to log aborted autovacuums
Date: 2011-02-05 20:25:19
Message-ID: AANLkTinqqHd-iOvxyPFBZkHDG7yb_4aZ846hDxgcrEeP@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Sat, Feb 5, 2011 at 3:20 PM, Cédric Villemain
<cedric(dot)villemain(dot)debian(at)gmail(dot)com> wrote:
>> 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 think a GUC just to control this one message is overkill.  Chances
are that if you're logging some or all of your autovacuum runs you'll
want to have this too, or at least it won't be a major problem to get
it anyway.  If for some reason you want ONLY this message, you can
effectively get that behavior too, but setting
log_autovacuum_min_duration to an enormous value.  So I can't really
imagine why you'd need a separate knob just for this one thing.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

pgsql-hackers by date

Next:From: Cédric VillemainDate: 2011-02-05 20:34:15
Subject: Re: We need to log aborted autovacuums
Previous:From: Cédric VillemainDate: 2011-02-05 20:20:57
Subject: Re: We need to log aborted autovacuums

Privacy Policy | About PostgreSQL
Copyright © 1996-2013 The PostgreSQL Global Development Group