Alvaro Herrera wrote:
> 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.
Evidently there is a problem right there. If I simply add an "order by
tenthous" as proposed by Peter, many more errors appear; and what errors
appear differs if I change shared_buffers. I think the real fix for
this is to change the hand-picked values used in the brinopers table, so
that they all pass the test using some reasonable ORDER BY specification
in the populating query (probably tenk1.unique1).
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
