Re: [HACKERS] brin regression test intermittent failures

Tom Lane wrote: > I wrote: > > The other cases that I found involve cidrcol, and seem to represent > > an actual bug in the brin planning logic, ie failure to disregard a > > no-op cast. I'll look closer. > > I leapt to the wrong conclusion on that one. The reason for failure to > match to an in

Re: [HACKERS] brin regression test intermittent failures

I wrote: > The other cases that I found involve cidrcol, and seem to represent > an actual bug in the brin planning logic, ie failure to disregard a > no-op cast. I'll look closer. I leapt to the wrong conclusion on that one. The reason for failure to match to an index column had nothing to do w

Re: [HACKERS] brin regression test intermittent failures

Alvaro Herrera writes: > Tom Lane wrote: >> Also, further experimentation shows that there are about 30 entries in the >> brinopers table that give rise to seqscan plans even when we're commanding >> a bitmap scan, presumably because those operators aren't brin-indexable. >> They're not the proble

Re: [HACKERS] 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.) >

Re: [HACKERS] brin regression test intermittent failures

Tom Lane wrote: > I wrote: > > 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. > > Also, further experimentation shows that there are about 30 entries i

Re: [HACKERS] brin regression test intermittent failures

Tom Lane wrote: > Alvaro Herrera 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-

Re: [HACKERS] brin regression test intermittent failures

I wrote: > 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. Also, further experimentation shows that there are about 30 entries in the brinopers table that g

Re: [HACKERS] brin regression test intermittent failures

Alvaro Herrera 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

Re: [HACKERS] brin regression test intermittent failures

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 mig

Re: [HACKERS] 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

Re: [HACKERS] brin regression test intermittent failures

Alvaro Herrera writes: > Tom Lane wrote: >> Fixed, see 79f2b5d583e2e2a7; but AFAICS this has no real-world impact >> so it does not explain whatever is happening on chipmunk. > Ah, thanks for diagnosing that. > The chipmunk failure is strange -- notice it only references the > = operators, excep

Re: [HACKERS] brin regression test intermittent failures

Tom Lane wrote: > Peter Geoghegan writes: > > I meant to get around to looking into it, but FWIW I see BRIN-related > > Valgrind issues. e.g.: > > Fixed, see 79f2b5d583e2e2a7; but AFAICS this has no real-world impact > so it does not explain whatever is happening on chipmunk. Ah, thanks for diag

Re: [HACKERS] brin regression test intermittent failures

I wrote: > Peter Geoghegan writes: >> I meant to get around to looking into it, but FWIW I see BRIN-related >> Valgrind issues. e.g.: > Fixed, see 79f2b5d583e2e2a7; but AFAICS this has no real-world impact > so it does not explain whatever is happening on chipmunk. BTW, after some further trawli

Re: [HACKERS] brin regression test intermittent failures

Peter Geoghegan writes: > I meant to get around to looking into it, but FWIW I see BRIN-related > Valgrind issues. e.g.: Fixed, see 79f2b5d583e2e2a7; but AFAICS this has no real-world impact so it does not explain whatever is happening on chipmunk. regards, tom lane --

Re: [HACKERS] brin regression test intermittent failures

On Mon, May 25, 2015 at 3:25 PM, Tom Lane wrote: > Also worth noting is that there's a completely different failure symptom > that's shown up a few times, eg here: > > http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=chipmunk&dt=2015-05-25%2009%3A56%3A55 > > This makes it look like brintest

Re: [HACKERS] brin regression test intermittent failures

Andrew Dunstan writes: > There's something odd about the brin regression tests. They seem to > generate intermittent failures, which suggests some sort of race > condition or ordering failure. > See for example >

Re: [HACKERS] brin regression test intermittent failures

Alvaro Herrera writes: > Tom Lane wrote: >> Just from reading the documentation, couldn't the symptom we're seeing >> arise from autovacuum having hit the table right before >> brin_summarize_new_values got called? > Well, I added a autovacuum_enabled=off to that table recently precisely > becaus

Re: [HACKERS] brin regression test intermittent failures

Tom Lane wrote: > Alvaro Herrera writes: > > Andrew Dunstan wrote: > >> There's something odd about the brin regression tests. They seem to > >> generate > >> intermittent failures, which suggests some sort of race condition or > >> ordering failure. > >> > >> See for example > >>

Re: [HACKERS] brin regression test intermittent failures

Alvaro Herrera writes: > Andrew Dunstan wrote: >> There's something odd about the brin regression tests. They seem to generate >> intermittent failures, which suggests some sort of race condition or >> ordering failure. >> >> See for example >>

Re: [HACKERS] brin regression test intermittent failures

Andrew Dunstan wrote: > > There's something odd about the brin regression tests. They seem to generate > intermittent failures, which suggests some sort of race condition or > ordering failure. > > See for example >

[HACKERS] brin regression test intermittent failures

There's something odd about the brin regression tests. They seem to generate intermittent failures, which suggests some sort of race condition or ordering failure. See for example and