Re: Decoding of (nearly) empty transactions and regression tests

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Decoding of (nearly) empty transactions and regression tests
Date: 2014-06-29 15:15:08
Message-ID: 20140629151508.GC26930@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2014-06-29 11:08:39 -0400, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-06-29 15:24:35 Re: Decoding of (nearly) empty transactions and regression tests
Previous Message Tom Lane 2014-06-29 15:08:39 Re: Decoding of (nearly) empty transactions and regression tests