Re: Failing assertions in indxpath.c, placeholder.c and brin_minmax.c
| От | Tom Lane |
|---|---|
| Тема | Re: Failing assertions in indxpath.c, placeholder.c and brin_minmax.c |
| Дата | |
| Msg-id | 25498.1438007327@sss.pgh.pa.us обсуждение |
| Ответ на | Re: Failing assertions in indxpath.c, placeholder.c and brin_minmax.c (Andreas Seltenreich <seltenreich@gmx.de>) |
| Список | pgsql-hackers |
Andreas Seltenreich <seltenreich@gmx.de> writes:
> Tom Lane writes:
>> I've fixed the first two of these --- thanks for the report!
> I let sqlsmith run during the night, and it did no longer trigger the
> first two. During roughly a million random queries it triggered the
> already mentioned brin one 10 times, but there was also one instance of
> this new one in the log:
Oh goody, more fun. I'll take a look.
>> I'm a bit confused about this aspect of your report though, because in
>> my hands that example fails clear back to 9.2. It doesn't seem to require
>> the predtest.c improvement to expose the fault.
> Hmm, I actually used a different, uglier query to trigger this assertion
> for the bisection run.
Ah, okay. The triggering condition for both those cases is
provably-contradictory restriction clauses on an inheritance relation.
In what you showed yesterday, that was something like "x < x AND x IS
NULL", which the planner has been able to recognize as contradictory
for a long time because "<" is strict. (It did not, and still doesn't,
notice that "x < x" all by itself is contradictory...). But here it
looks like the trigger is
from public.b as rel4551420
where ( rel4551420.bb>rel4551420.bb ) and ( rel4551420.bb<rel4551420.bb )
It was the recent predtest improvements that allowed recognition that
bb < bb contradicts bb > bb. So that's why this run started to fail
there, even though the bug it was tickling is much older.
regards, tom lane
В списке pgsql-hackers по дате отправления: