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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
