Re: We need to log aborted autovacuums - Mailing list pgsql-hackers

From Cédric Villemain
Subject Re: We need to log aborted autovacuums
Date
Msg-id AANLkTimiHq4QUZnVPS0AayeJ=RaDThoyFQA=w1R8pZaD@mail.gmail.com
Whole thread Raw
In response to Re: We need to log aborted autovacuums  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: We need to log aborted autovacuums
List pgsql-hackers
2011/2/5 Robert Haas <robertmhaas@gmail.com>:
> On Sat, Feb 5, 2011 at 3:20 PM, Cédric Villemain
> <cedric.villemain.debian@gmail.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.

to not output it when I want log_autovac_min_duration = 0 but I know
that some tables do have locks contention and may loose maintenance
for one hour or so.

Anyway, without GUC is fine too as it won't fill the /var/log itself !
I am just not opposed to have new GUC in those areas (log && debug).

--
Cédric Villemain               2ndQuadrant
http://2ndQuadrant.fr/     PostgreSQL : Expertise, Formation et Support


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: We need to log aborted autovacuums
Next
From: "Kevin Grittner"
Date:
Subject: Re: SSI patch version 14