Re: Autovacuum-induced regression test instability
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2019-04-16T05:53:12Z
Lists: pgsql-hackers
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
Commits
-
Avoid possible regression test instability in timestamp.sql.
- 47169c25500a 12.0 landed