Tom Lane wrote:
My objection here is basically that this proposal passed on the
assumption that it would be very nearly zero effort to make it happen.
We are now finding out that we have a fair amount of work to do if we
want autovac to not mess up the regression tests, and I think that has
Andreas Pflug [EMAIL PROTECTED] writes:
Tom Lane wrote:
My objection here is basically that this proposal passed on the
assumption that it would be very nearly zero effort to make it happen.
Kicking out autovacuum as default is a disaster, it took far too long to
get in the backend already
Am Dienstag, 29. August 2006 11:14 schrieb Andreas Pflug:
already pointed out, all win32 installations have it on by default, to
take them to the safe side. Disabling it for modules a retail user
will never launch appears overreacting.
Well, the really big problem is that autovacuum may be
Tom Lane wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
Tom Lane wrote:
My objection here is basically that this proposal passed on the
assumption that it would be very nearly zero effort to make it happen.
Kicking out autovacuum as default is a disaster, it took far
Peter Eisentraut wrote:
Am Dienstag, 29. August 2006 11:14 schrieb Andreas Pflug:
already pointed out, all win32 installations have it on by default, to
take them to the safe side. Disabling it for modules a retail user
will never launch appears overreacting.
Well, the really big
Folks,
My vote is with Peter and Tom on not putting it in. We needed to discuss/test
this well before feature freeze if we really wanted to do it.
Here's what needs to be resolved:
a) make autovaccum play nice with the regression tests
b) come up with default threshold/multiplier values which
I think we shall have to reconsider that patch to turn it on by default.
So far I've seen two categories of failure:
* manual ANALYZE issued by regression tests fails because autovac is
analyzing the same table concurrently.
* contrib tests fail in their repeated drop/create database operations
Tom Lane wrote:
I think we shall have to reconsider that patch to turn it on by
default. So far I've seen two categories of failure:
So we turn autovacuum off for regression test instance.
* manual ANALYZE issued by regression tests fails because autovac is
analyzing the same table
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
I think we shall have to reconsider that patch to turn it on by
default. So far I've seen two categories of failure:
So we turn autovacuum off for regression test instance.
Not a solution for make installcheck, unless you are
Tom Lane wrote:
So we turn autovacuum off for regression test instance.
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
I wrote:
BTW, it would sure be nice to know what happened here:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=waspdt=2006-08-28%2017:05:01
LOG: autovacuum process (PID 26315) was terminated by signal 11
I was able to cause autovac to crash by repeating contrib/intarray
regression test
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=ospreydt=2006-08-28%2016:00:17
shows another autovac-induced failure mode:
! psql: FATAL: sorry, too many clients already
initdb is choosing max_connections = 20 on this machine, which is
sufficient to run the parallel regression tests by
On Mon, 2006-08-28 at 15:21 -0400, Tom Lane wrote:
We have more than enough problems to fix for 8.2 already. Let's
try to do this early in the 8.3 cycle instead.
I agree -- I think this is exactly the sort of change that is best made
at the beginning of a development cycle, so that there's a
Neil Conway wrote:
On Mon, 2006-08-28 at 15:21 -0400, Tom Lane wrote:
We have more than enough problems to fix for 8.2 already. Let's
try to do this early in the 8.3 cycle instead.
I agree -- I think this is exactly the sort of change that is best made
at the beginning of a development
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
Matthew T. O'Connor matthew@zeut.net writes:
Tom Lane wrote:
Not a solution for make installcheck,
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?
16 matches
Mail list logo
