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.
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 |