Re: autovacuum causing numerous regression-test failures
От | Peter Eisentraut |
---|---|
Тема | Re: autovacuum causing numerous regression-test failures |
Дата | |
Msg-id | 200608282139.00561.peter_e@gmx.net обсуждение исходный текст |
Ответ на | Re: autovacuum causing numerous regression-test failures (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: autovacuum causing numerous regression-test failures
Re: autovacuum causing numerous regression-test failures |
Список | pgsql-hackers |
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 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. > > 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. > > I opine that when a database is to be dropped, the connections > > should be cut. > > Sure, but that's another thing that we're not going to start > designing and implementing four weeks after feature freeze. Right. > clear that that is not the case, and I don't think it makes any sense > from a project-management standpoint to try to flush the problems out > at this time in the release cycle. 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. Let's just consider some of the options a bit more closely, and if they don't work, we'll revert it. -- Peter Eisentraut http://developer.postgresql.org/~petere/
В списке pgsql-hackers по дате отправления: