Re: brin regression test intermittent failures

Alvaro Herrera  writes:
> Tom Lane wrote:
>> I may be confused, but why would the physical ordering of the table
>> entries make a difference to the correct answers for this test?
>> (I can certainly see why that might break the brin code, but not
>> why it should change the seqscan's answers.)

> We create the brintest using a scan of tenk1 LIMIT 100, without
> specifying the order.  So whether we find rows that match each test query
> is pure chance.

Oooh ... normally that would not matter, but I wonder if what's happening
on chipmunk is that the synchronized-seqscan logic kicks in and causes us
to read some other part of tenk1 than we normally would, as a consequence
of some concurrent activity or other.  The connection to smaller than
normal shared_buffers would be that it would change our idea of what's a
large enough table to justify using synchronized seqscans.

Peter's patch failed to hit the place where this matters, btw.
		regards, tom lane