On 2014-05-25 16:58:39 -0400, Tom Lane wrote: > Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
