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: 44F370A7.708@zeut.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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.

Agreed.

In response to

Responses

Browse pgsql-hackers by date

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