From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andreas Seltenreich <seltenreich(at)gmx(dot)de> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [sqlsmith] Failed assertion in joinrels.c |
Date: | 2015-08-01 01:11:23 |
Message-ID: | 15630.1438391483@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andreas Seltenreich <seltenreich(at)gmx(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2015-08-01 03:29:51 | Re: Solaris testers wanted for strxfrm() behavior |
Previous Message | Andreas Seltenreich | 2015-08-01 00:56:22 | [sqlsmith] Failed assertion in joinrels.c |