There may be other errors that would be surprising for Tom or Robert. What I did with the string argument fuzzer was printed counts for each sqlstate for the errors and watched for errors that only occurred occasionally or didn't make sense to me.
Also, do you have any timeouts? Do you have any stats on how long these queries are taking to plan? What's the longest query to plan you've found?
Do you have coverage data for the corpus? Maybe we could suggest syntaxes specifically aimed at getting coverage for sections of chose that don't have any yet.
On 11 Dec 2015 19:25, "Peter Geoghegan" <
pg@heroku.com> wrote:
On Fri, Dec 11, 2015 at 7:58 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I guess that means I have to go back to extending the grammar again :-).
>
> I await the results with interest. Did you note the suggestion about
> trying to stress the ON CONFLICT code with this? You'd need it to
> issue non-SELECT queries, which might create some reproducibility
> issues...
About 80% of the bugs we've seen so far are the type that a tool like
sqlsmith could plausibly catch: bugs that trigger defensive "can't
happen" elog(ERROR, ... ) calls within the planner and rewriter. While
I've been vigilant, I certainly wouldn't be surprised if more were
found, given the total flexibility of the ON CONFLICT syntax.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
