Re: brin regression test intermittent failures

Tom Lane wrote:

> Actually not --- if you browse through the last half dozen failures
> on chipmunk you will notice that
>
> (1) the set of operators complained of varies a bit from one failure
> to the next;
>
> (2) more often than not, this is one of the failures:
>
> WARNING: no results for (boxcol,@>,box,"((1,2),(300,400))")
>
> Certainly the majority of the complaints are about equality operators,
> but not quite all of them.

Hm. Well, what this message says is that we ran that query using
both BRIN and seqscan, and that in both cases no row was returned. Note
that if the BRIN and seqscan cases had returned different sets of rows,
the error message would have been different. So this might be related
to the way the test table is created, rather than to a bug in BRIN.
Peter G. recently pointed out that this seems to be relying on an
index-only scan on table tenk1 and suggested an ORDER BY. Maybe that
assumption is being violated on chipmunk and so the table populated is
different than what the table actually expects.

I just noticed that chipmunk has shared_buffers=10MB on its buildfarm
config. I don't see that in any of the other ARM animals. Maybe that
can change the plan choice.

I will test locally with reduced shared_buffers and see if I can
reproduce the results.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services