I wrote:
> Anyway, I remain suspicious that the instability is the fault
> of something in the statistics code, not of autovacuum.
I've been trying to reproduce this by dint of running just the stats_ext
script, over and over in a loop. I've not had any success on fast
machines, but on a slow one (florican's host) I got this after a few
hundred iterations:
diff -U3 /usr/home/tgl/pgsql/src/test/regress/expected/stats_ext.out
/usr/home/tgl/pgsql/src/test/regress/results/stats_ext.out
--- /usr/home/tgl/pgsql/src/test/regress/expected/stats_ext.out 2020-03-30 21:15:19.749874000 -0400
+++ /usr/home/tgl/pgsql/src/test/regress/results/stats_ext.out 2020-03-30 22:29:04.062103000 -0400
@@ -1172,7 +1172,7 @@
SELECT * FROM check_estimated_rows('SELECT * FROM mcv_lists WHERE a = 1 AND b = ''1''');
estimated | actual
-----------+--------
- 1 | 50
+ 50 | 50
(1 row)
VACUUM (ANALYZE) mcv_lists;
Now this *IS* autovacuum interference, but it's hardly autovacuum's fault:
the test script is supposing that autovac won't come in before it does a
manual analyze, and that's just unsafe on its face.
I'm thinking that what we ought to do is have this test disable autovac
altogether on its tables, ie
CREATE TABLE ... WITH (autovacuum_enabled = off);
However, I remain suspicious that there's something else going on,
unrelated to autovac. All the buildfarm cases so far have been
small underestimates, one or two rows, so they look entirely different
from the example above. Even if autovacuum is firing unexpectedly,
how would it cause such results?
regards, tom lane
