From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Stephen Frost <sfrost(at)snowman(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Fuzz testing COPY FROM parsing |
Date: | 2021-02-05 20:11:35 |
Message-ID: | 126590.1612555895@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Heikki Linnakangas <hlinnaka(at)iki(dot)fi> writes:
> That said, I don't think it's important to run the fuzzer in the
> buildfarm. It should be enough to do that every once in a while, when
> you modify the COPY FROM code (or something else that you want to fuzz
> test). But we could easily include the test inputs generated by the
> fuzzer in the regular tests. We've usually been very frugal in adding
> tests, though, to keep the time it takes to run all the tests short.
Yeah, I think there's a lot of value in the fact that it doesn't
take too long to run the core regression tests, or even check-world.
Also, given you mentioned that this fuzzer bases its work partly
on code examination, it seems like the right procedure would be to
re-invoke the fuzzer after changes, not just blindly re-use the
test cases it made for the old code. So it seems like the thing
we want here is documentation or a test harness for using the
fuzzer, but not direct incorporation of test cases.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jacob Champion | 2021-02-05 20:22:40 | More test/kerberos tweaks |
Previous Message | Tom Lane | 2021-02-05 20:07:16 | First-draft release notes for back branches are up |