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