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 a
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
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 disa
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
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 a
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 h
"Matthew T. O'Connor" 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?
Well
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
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 develo
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
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=osprey&dt=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 themse
I wrote:
> BTW, it would sure be nice to know what happened here:
> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=wasp&dt=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
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, t
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 ar
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 concur
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
b
16 matches
Mail list logo