Re: Fuzz testing COPY FROM parsing

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

In response to

Browse pgsql-hackers by date

  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