Search Postgresql Archives

Re: Autovacuum Logging

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Well, one problem now is that everytime pg_autovacuum opens a database,
a message is placed in the logs:
	
	LOG:  autovacuum: processing database "test"
	LOG:  autovacuum: processing database "test"
	LOG:  autovacuum: processing database "test"
	LOG:  autovacuum: processing database "test"

This is certainly not desirable.  I changed the message to DEBUG1 for
8.2 with the attached patch.  I also added a sentence to the
log_min_error_messages TODO item:
	
	* Allow log_min_messages to be specified on a per-module basis
	
	  This would allow administrators to see more detailed information from
	  specific sections of the backend, e.g. checkpoints, autovacuum, etc.
	  Another idea is to allow separate configuration files for each module,
	  or allow arbitrary SET commands to be passed to them.

I am thinking the new second sentence is more flexible than just making
a change for log_min_error_messages.

---------------------------------------------------------------------------

Matthew T. O'Connor wrote:
> Right, I think there has been discussion about this and general 
> agreement that the current autovacuum logging options are less than 
> ideal to put it mildly.  Unfortunately, I don't think there has been any 
> action by anyone to do something about it.  I hope to work on this at 
> some point, but coding time for PG scarce resource in my life, so no 
> promises.
> 
> Matt
> 
> 
> 
> Will Reese wrote:
> > I found this short discussion between Tom and Bruce, but that's about it 
> > for autovacuum logging.
> > 
> > http://archives.postgresql.org/pgsql-general/2006-04/msg00489.php
> > 
> > It just seems like the "processing database" log statement should be set 
> > to a lower level, since it just logs every time autovacuum runs.  And 
> > the "vacuum table" log statement should be set to LOG since it will only 
> > log when it actually vacuums a table, which is very useful and important 
> > information.  If Bruce's solution is implemented in 8.2 that would be 
> > nice, but raising the log level from DEBUG2 to LOG would be a nice patch 
> > for 8.1.4 in the meantime.  :)
> > 
> > 
> > Will Reese -- http://blog.rezra.com
> > 
> > On Apr 27, 2006, at 12:20 AM, Jim C. Nasby wrote:
> > 
> >> I believe 8.2 will have improved autovac logging. Take a look in the
> >> -hackers archives for more info.
> >>
> >> On Wed, Apr 26, 2006 at 10:47:26PM -0500, Will Reese wrote:
> >>> Is there a reason many of the most useful autovacuum.c elog
> >>> statements are set to DEBUG2?  It seems to me that these should be
> >>> set to LOG.
> >>>
> >>> I used autovacuum when it was a contrib module, and it failed after a
> >>> month.  To prevent major performance problems I went back to the
> >>> daily vacuum.  I was looking forward to using autovacuum in 8.1 since
> >>> it is more resilient and configurable now, but when I noticed it
> >>> would not log it's activities I almost decided against it.  After
> >>> looking at the source code it seems that all the necessary logging is
> >>> built in, it's just not set to the appropriate log level.  I'm sure
> >>> I'm not the only person interested in this, and I saw somewhere (I
> >>> can't find it again) that EnterpriseDB has enabled autovacuum
> >>> logging.  I don't think it's too verbose to change these to the
> >>> normal log level, but if so could it be a postgresql.conf option to
> >>> enable/disable autovacuum logging?  It sure would be nice to be able
> >>> to verify that tables are being vacuumed properly without having to
> >>> set the log level to DEBUG2.
> >>>
> >>> Will Reese -- http://blog.rezra.com
> >>>
> >>> ---------------------------(end of broadcast)---------------------------
> >>> TIP 6: explain analyze is your friend
> >>>
> >>
> >> --Jim C. Nasby, Sr. Engineering Consultant      jnasby@xxxxxxxxxxxxx
> >> Pervasive Software      http://pervasive.com    work: 512-231-6117
> >> vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461
> > 
> > 
> > ---------------------------(end of broadcast)---------------------------
> > TIP 6: explain analyze is your friend
> > 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
>        subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your
>        message can get through to the mailing list cleanly
> 

-- 
  Bruce Momjian   http://candle.pha.pa.us
  EnterpriseDB    http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +
Index: src/backend/postmaster/autovacuum.c
===================================================================
RCS file: /cvsroot/pgsql/src/backend/postmaster/autovacuum.c,v
retrieving revision 1.16
diff -c -c -r1.16 autovacuum.c
*** src/backend/postmaster/autovacuum.c	6 Apr 2006 20:38:00 -0000	1.16
--- src/backend/postmaster/autovacuum.c	27 Apr 2006 15:54:56 -0000
***************
*** 412,418 ****
  		InitPostgres(db->name, NULL);
  		SetProcessingMode(NormalProcessing);
  		set_ps_display(db->name);
! 		ereport(LOG,
  				(errmsg("autovacuum: processing database \"%s\"", db->name)));
  
  		/* Create the memory context where cross-transaction state is stored */
--- 412,418 ----
  		InitPostgres(db->name, NULL);
  		SetProcessingMode(NormalProcessing);
  		set_ps_display(db->name);
! 		ereport(DEBUG1,
  				(errmsg("autovacuum: processing database \"%s\"", db->name)));
  
  		/* Create the memory context where cross-transaction state is stored */

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux