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

Re: autovacuum causing numerous regression-test failures

From: "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: autovacuum causing numerous regression-test failures
Date: 2006-08-28 22:39:35
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Peter Eisentraut wrote:
> Tom Lane wrote:
>> Not a solution for "make installcheck",
> Well, for "make installcheck" we don't have any control over whether 
> autovacuum has been turned on or off manually anyway.  If you are 
> concerned about build farm reliability, the build farm scripts can 
> surely be made to initialize or start the instance in a particular way.
> Another option might be to turn off stats_row_level on the fly.

I'm sure I'm missing some of the subtleties of make installcheck issues, 
but autovacuum can be enabled / disabled on the fly just as easily as 
stats_row_level, so I don't see the difference?

>>> Or we put manual exceptions for the affected tables into
>>> pg_autovacuum.
>> New feature?  Or does that capability exist already?
> I haven't ever used the pg_autovacuum table but the documentation 
> certainly makes one believe that this is possible.

Right, if it doesn't work, that would certainly be a bug.  This feature 
was included during the original integration into the backend during the 
8.0 dev cycle.

> Let's just consider some of the options a bit more closely, and if they 
> don't work, we'll revert it.


In response to


pgsql-hackers by date

Next:From: Bruce MomjianDate: 2006-08-28 22:47:31
Subject: Re: [HACKERS] Performance testing of COPY (SELECT)
Previous:From: Chris MairDate: 2006-08-28 22:38:49
Subject: Re: [PATCHES] updated patch for selecting large results

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