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