David Rowley writes:
> Can you share which failure you're talking about here? All of the
> ones I've looked at were failing post-ANALYZE.
It's what I posted yesterday:
diff -U3 /usr/home/tgl/pgsql/src/test/regress/expected/stats_ext.out
/usr/home/tgl/pgsql/src/test/regress/results/stats_ext.ou
On Wed, 1 Apr 2020 at 13:00, Tom Lane wrote:
>
> David Rowley writes:
> > On Tue, 31 Mar 2020 at 15:55, Tom Lane wrote:
> >> 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 analyz
David Rowley writes:
> On Tue, 31 Mar 2020 at 15:55, Tom Lane wrote:
>> 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.
> Why would that m
On Tue, 31 Mar 2020 at 15:55, Tom Lane wrote:
> 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:
I've had a 13
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
I wrote:
> Specifically, I notice that in the last couple of failures involving
> tests on "mcv_lists", we are considering stats on a 5000-row table.
> With the standard setting default_statistics_target = 100, ANALYZE
> will take a 3000-row random sample, meaning that its results are
> *inherently
David Rowley writes:
> Attempt to fix unstable regression tests, take 2
That still isn't working, and I'm starting to think that we're
blaming the messenger. To wit, what we are seeing here is that
these tests are unstable ... and that's a bug of the tests, not of
any adjustments of autovacuum t
Attempt to fix unstable regression tests, take 2
Following up on 2dc16efed, petalura has suffered some additional
failures in stats_ext which again appear to be around the timing of an
autovacuum during the test, causing instability in the row estimates.
Again, let's fix this by explicitly perfor
Attempt to fix unstable regression tests
b07642dbc added code to trigger autovacuums based on the number of
inserts into a table. This seems to have caused some regression test
results to destabilize. I suspect this is due to autovacuum triggering a
vacuum sometime after the test's ANALYZE run and
