Re: Sending out a request for more buildfarm animals?

On 2014-05-25 16:58:39 -0400, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > On 2014-05-25 01:02:25 +0200, Tomas Vondra wrote:
> >> The cache invalidation bug was apparently fixed, but we're still getting
> >> failures (see for example markhor):
> >> http://www.pgbuildfarm.org/cgi-bin/show_history.pl?nm=markhor&br=HEAD
> >> I see there's a transaction (COMMIT+BEGIN) - is this caused by the
> >> extremely long runtimes?
> 
> > Yes, that's the reason. Normally the test doesn't trigger autovacuum at
> > all, but if it's running for a *long* time it can. I haven't yet figured
> > out a good way to deal with that.
> 
> Any way to make the test print only WAL entries arising from the
> foreground transaction?

None that doesn't suck, so far :(. The least bad I can think of is toe
just add a xinfo flag for such 'background' transaction commits. Don't
like it much...

> If an autovac run can trigger this failure, then I would think it would
> happen sometimes, probabilistically, even when the test runtime wasn't
> all that long.  That would be very unhappy-making, eg for packagers
> who would like build runs to reliably work the first time.  So I think
> this is important even without the desire to run CLOBBER_CACHE regression
> tests.

Agreed.

> Another idea is to provide a variant "expected" file, but that seems
> a bit fragile: if you can get one extra transaction, why not two?

Yeah, that's not going to work. Autovac's transaction could appear at
different places in the changestream. We probably don't want a expected
file listing all.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services