Re: We need to log aborted autovacuums
Cédric Villemain <cedric.villemain.debian@gmail.com>
From: Cédric Villemain <cedric.villemain.debian@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Alvaro Herrera <alvherre@commandprompt.com>, Tom Lane <tgl@sss.pgh.pa.us>, Simon Riggs <simon@2ndquadrant.com>, Josh Berkus <josh@agliodbs.com>, Greg Smith <greg@2ndquadrant.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2011-02-05T20:34:15Z
Lists: 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