From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Peter Geoghegan <pg(at)heroku(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: brin regression test intermittent failures |
Date: | 2015-06-04 17:17:30 |
Message-ID: | 20150604171730.GI133018@postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> > 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).
>
> 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.
> Also, what I'd just noticed is that all of the cases that are failing are
> ones where the expected number of matching rows is exactly 1. I am
> wondering if the test is sometimes just missing random rows, and we're not
> seeing any reported problem unless that makes it go down to no rows. (But
> I do not know how that could simultaneously affect the seqscan case ...)
Yeah, we compare the ctid sets of the results, and we assume that a
seqscan would get that correctly.
> I think it would be a good idea to extend the brinopers table to include
> the number of expected matches, and to complain if that's not what we got,
> rather than simply checking for zero.
That sounds reasonable.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2015-06-04 17:24:51 | Re: brin regression test intermittent failures |
Previous Message | Tom Lane | 2015-06-04 17:14:59 | Re: brin regression test intermittent failures |