[HACKERS] Ancient row-ordering instability in regression tests

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