I noticed that skink failed today with a row-ordering difference:

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".


                        regards, tom lane

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to