Autovacuum-induced regression test instability

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Autovacuum-induced regression test instability

Tom Lane-2
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');
Reply | Threaded
Open this post in threaded view
|

Re: Autovacuum-induced regression test instability

Michael Paquier-2
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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Autovacuum-induced regression test instability

Tom Lane-2
Michael Paquier <[hidden email]> 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