Thread: Autovacuum-induced regression test instability

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?

            regards, tom lane

[1] https://www.postgresql.org/message-id/15751.1555256860%40sss.pgh.pa.us

diff --git a/src/test/regress/expected/timestamp.out b/src/test/regress/expected/timestamp.out
index 4a2fabd..b2b171f 100644
--- a/src/test/regress/expected/timestamp.out
+++ b/src/test/regress/expected/timestamp.out
@@ -74,7 +74,7 @@ SELECT count(*) AS two FROM TIMESTAMP_TBL WHERE d1 = timestamp(2) without time z
 (1 row)

 COMMIT;
-DELETE FROM TIMESTAMP_TBL;
+TRUNCATE TIMESTAMP_TBL;
 -- Special values
 INSERT INTO TIMESTAMP_TBL VALUES ('-infinity');
 INSERT INTO TIMESTAMP_TBL VALUES ('infinity');
diff --git a/src/test/regress/sql/timestamp.sql b/src/test/regress/sql/timestamp.sql
index b7957cb..150eb54 100644
--- a/src/test/regress/sql/timestamp.sql
+++ b/src/test/regress/sql/timestamp.sql
@@ -44,7 +44,7 @@ SELECT pg_sleep(0.1);
 SELECT count(*) AS two FROM TIMESTAMP_TBL WHERE d1 = timestamp(2) without time zone 'now';
 COMMIT;

-DELETE FROM TIMESTAMP_TBL;
+TRUNCATE TIMESTAMP_TBL;

 -- Special values
 INSERT INTO TIMESTAMP_TBL VALUES ('-infinity');

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