Re: Decoding of (nearly) empty transactions and regression tests - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Decoding of (nearly) empty transactions and regression tests
Date
Msg-id 20140629151508.GC26930@awork2.anarazel.de
Whole thread Raw
In response to Re: Decoding of (nearly) empty transactions and regression tests  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Decoding of (nearly) empty transactions and regression tests  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 2014-06-29 11:08:39 -0400, Tom Lane wrote:
> Andres Freund <andres@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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Decoding of (nearly) empty transactions and regression tests
Next
From: Tom Lane
Date:
Subject: Re: Decoding of (nearly) empty transactions and regression tests