Re: [sqlsmith] Failed assertion in joinrels.c - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [sqlsmith] Failed assertion in joinrels.c
Date
Msg-id 15630.1438391483@sss.pgh.pa.us
Whole thread Raw
In response to [sqlsmith] Failed assertion in joinrels.c  (Andreas Seltenreich <seltenreich@gmx.de>)
Responses Re: [sqlsmith] Failed assertion in joinrels.c  (Andreas Seltenreich <seltenreich@gmx.de>)
List pgsql-hackers
Andreas Seltenreich <seltenreich@gmx.de> writes:
> sqlsmith triggered the following assertion in master (c188204).

> TRAP: FailedAssertion("!(!bms_overlap(joinrelids, sjinfo->min_lefthand))", File: "joinrels.c", Line: 500)

Cool, I'll take a look.

> As usual, the query is against the regression database.  It is rather
> unwieldy… I wonder if I should stop working on new grammar rules and
> instead work on some post-processing that prunes the AST as much as
> possible while maintaining the failure mode.

Probably not really worth the trouble; I find it's usually easy to
produce a minimized test case after the failure cause is understood.

What concerns me more is that what you're finding is only cases that trip
an assertion sanity check.  It seems likely that you're also managing to
trigger other bugs with less drastic consequences, such as "could not
devise a query plan" failures or just plain wrong answers.  I'm not sure
how we could identify wrong answers automatically :-( but it might be
worth checking for XX000 SQLSTATE responses, since generally that should
be a can't-happen case.  (Or if it can happen, we need to change the
errcode.)
        regards, tom lane



pgsql-hackers by date:

Previous
From: Andreas Seltenreich
Date:
Subject: [sqlsmith] Failed assertion in joinrels.c
Next
From: Josh Berkus
Date:
Subject: Re: Solaris testers wanted for strxfrm() behavior