Re: [HACKERS] pgstat delay in autovacuum

2008-11-03 Thread Alvaro Herrera
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > With the new request-based pgstat reading mechanism, it is easy to fix
> > an autovacuum "bug".  Basically for an autovac worker the delay is
> > reduced, so that the data is very fresh.  Patch attached.
> 
> It would be nice if the patch didn't render the adjacent comment a lie.

Yep, thanks -- fixed and committed.

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] pgstat delay in autovacuum

2008-11-03 Thread Tom Lane
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> With the new request-based pgstat reading mechanism, it is easy to fix
> an autovacuum "bug".  Basically for an autovac worker the delay is
> reduced, so that the data is very fresh.  Patch attached.

It would be nice if the patch didn't render the adjacent comment a lie.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


[HACKERS] pgstat delay in autovacuum

2008-11-03 Thread Alvaro Herrera
Hi,

With the new request-based pgstat reading mechanism, it is easy to fix
an autovacuum "bug".  Basically for an autovac worker the delay is
reduced, so that the data is very fresh.  Patch attached.

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
*** src/backend/postmaster/autovacuum.c	2 Nov 2008 21:24:52 -	1.85
--- src/backend/postmaster/autovacuum.c	3 Nov 2008 16:39:10 -
***
*** 2149,2156 
  		 * It could have changed if something else processed the table while
  		 * we weren't looking.
  		 *
! 		 * FIXME we ignore the possibility that the table was finished being
! 		 * vacuumed in the last 500ms (PGSTAT_STAT_INTERVAL).  This is a bug.
  		 */
  		MemoryContextSwitchTo(AutovacMemCxt);
  		tab = table_recheck_autovac(relid, table_toast_map);
--- 2149,2157 
  		 * It could have changed if something else processed the table while
  		 * we weren't looking.
  		 *
! 		 * Note: we have a special case in pgstat code to ensure that the stats
! 		 * we read are as up-to-date as possible, to avoid the problem that
! 		 * somebody just finished vacuuming this table.
  		 */
  		MemoryContextSwitchTo(AutovacMemCxt);
  		tab = table_recheck_autovac(relid, table_toast_map);
*** src/backend/postmaster/pgstat.c	3 Nov 2008 01:17:08 -	1.182
--- src/backend/postmaster/pgstat.c	3 Nov 2008 16:37:13 -
***
*** 3389,3396 
  	 * PGSTAT_STAT_INTERVAL; and we don't want to lie to the collector about
  	 * what our cutoff time really is.
  	 */
! 	min_ts = TimestampTzPlusMilliseconds(GetCurrentTimestamp(),
! 		 -PGSTAT_STAT_INTERVAL);
  
  	/*
  	 * Loop until fresh enough stats file is available or we ran out of time.
--- 3389,3400 
  	 * PGSTAT_STAT_INTERVAL; and we don't want to lie to the collector about
  	 * what our cutoff time really is.
  	 */
! 	if (IsAutoVacuumWorkerProcess())
! 		min_ts = TimestampTzPlusMilliseconds(GetCurrentTimestamp(),
! 			 -PGSTAT_RETRY_DELAY);
! 	else
! 		min_ts = TimestampTzPlusMilliseconds(GetCurrentTimestamp(),
! 			 -PGSTAT_STAT_INTERVAL);
  
  	/*
  	 * Loop until fresh enough stats file is available or we ran out of time.

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers