Autovacuum-induced regression test instability

On Mon, Apr 15, 2019 at 01:22:30PM -0400, Tom Lane wrote:

In connection with the issue discussed at [1], I tried to run
the core regression tests with extremely aggressive autovacuuming
(I set autovacuum_naptime = 1s, autovacuum_vacuum_threshold = 5,
autovacuum_vacuum_cost_delay = 0). I found that the timestamp
test tends to fail with diffs caused by unstable row order in
timestamp_tbl. This is evidently because it does a couple of
DELETEs before inserting the table's final contents; if autovac
comes along at the right time then some of those slots can get
recycled in between insertions. I'm thinking of committing the
attached patch to prevent this, since in principle such failures
could occur even without hacking the autovac settings. Thoughts?

Aren't extra ORDER BY clauses the usual response to tuple ordering? I
really think that we should be more aggressive with that. For table
AM, it can prove to be very useful to run the main regression test
suite with default_table_access_method enforced, and most likely AMs
will not ensure the same tuple ordering as heap.
--
Michael

Michael Paquier <michael@paquier.xyz> writes:

Aren't extra ORDER BY clauses the usual response to tuple ordering? I
really think that we should be more aggressive with that.

I'm not excited about that. The traditional argument against it
is that if we start testing ORDER BY queries exclusively (and it
would have to be pretty nearly exclusively, if we were to take
this seriously) then we'll lack test coverage for queries without
ORDER BY. Also, regardless of whether you think that regression
test results can be kicked around at will, we are certainly going
to hear complaints from users if traditional behaviors like
"inserting N rows into a new table, then selecting them, gives
those rows back in the same order" go away. Recall that we had
to provide a way to disable the syncscan optimization because
some users complained about the loss of row-ordering consistency.

regards, tom lane