I noticed that skink failed today with a row-ordering difference: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink&dt=2017-02-04%2009%3A40%3A01
Looking at the regression test operations that change table onek2, I think the blame has to fall on this sequence in the "misc" test: DELETE FROM onek2; COPY onek2 FROM '@abs_builddir@/results/onek.data'; Presumably, what happened on "skink" is that a background autovacuum started cleaning up the DELETE's detritus before the COPY finished, allowing rows inserted by COPY to go into the table out-of-order. We could replace the DELETE with a TRUNCATE, but that would change the test conditions. Basically always up to this point, onek2 has had a bunch of dead rows that might get vacuumed away at some point in the tests, and I'm a bit loath to discard that. A slightly better option is to wrap this sequence in BEGIN/COMMIT so that the DELETE's not committed done until after the COPY. Or we could leave it alone, but I dislike regression tests that sometimes fail, even if "sometimes" is "only once in years". Thoughts? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers