On 2014-06-29 11:08:39 -0400, Tom Lane wrote: > Andres Freund <and...@2ndquadrant.com> writes: > > On 2014-06-29 10:36:22 -0400, Tom Lane wrote: > >> You mean disable autovac only in the contrib/test_decoding check run, > >> right? That's probably OK since it's tested in the main regression > >> runs. > > > Actually I'd not even though of that, but just of disabling it on > > relations with relevant amounts of changes in the test_decoding > > tests. That way it'd work even when run against an existing server (via > > installcheck-force) which I found useful during development. > > I think that a change that affects the behavior in any other test runs is > not acceptable. Our testing of autovac is weaker than I'd like already > (since the main regression runs are designed to not show visible changes > when it runs). I don't want it being turned off elsewhere for the benefit > of this test.
Hm? I think we're misunderstanding each other - I was thinking of tacking ALTER TABLE .. SET (AUTOVACUUM_ENABLED = false) to the tables created in test_decoding/sql/, not to something outside. Since we ignore transactions in other databases and the tests run in a database freshly created by pg_regress that should get rid of spurious transactions. Unless somebody fiddled with the template database or is close to a wraparound - but I'd be pretty surprised if that wouldn't cause failures in other tests as wel. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
