From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Autovacuum-induced regression test instability |
Date: | 2019-04-16 05:53:12 |
Message-ID: | 20190416055312.GG2673@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2019-04-16 06:13:00 | Re: Accidental setting of XLogReaderState.private_data ? |
Previous Message | Noah Misch | 2019-04-16 05:47:21 | Re: extensions are hitting the ceiling |