On Fri, Jul 01, 2016 at 08:09:07PM -0700, Peter Geoghegan wrote:
> On Fri, Jul 1, 2016 at 7:05 PM, Noah Misch <noah@leadboat.com> wrote:
> > I think such a test would suffice to cover this bug if Valgrind Memcheck does
> > detect the problem in it.
>
> Are you asking me to produce a regression test that exercises the bug?
Yes, please produce a patch version bearing a regression test that exercises
the bug. I feel it counts even if the you need Valgrind Memcheck to see that
it exercises the bug, but I won't interfere if Robert disagrees. The test
should take moderate steps to minimize costs. For example, it should decrease
maintenance_work_mem, not sort >16 MiB of data.
> I would be happy to do so, but I require some clarification on project
> policy first. As I already mentioned, we currently have *precisely*
> zero test coverage of external sorting. Apparently, avoiding external
> sort operations in the regression tests has value.
PostgreSQL is open to moving features from zero test coverage to nonzero test
coverage. The last several releases have each done so. Does that
sufficiently clarify the policy landscape?
> I think that a new tuplesort.sql test file is where a test like this
> belongs (not in the existing cluster.sql test file). If I write a
> patch along those lines, is it ever going to be accepted? I would be
> happy to work on this, but we need to have a sensible conversation on
> what's acceptable to everyone in this area first. I've screamed bloody
> murder about the test coverage in this area before, and nothing
> happened.
I'll guess that Robert would prefer a minimal test in cluster.sql over
starting a new file. If you want to be sure, wait for his input.
> If you think I'm overstating things, then consider how many commits
> that touched tuplesort.c added any tests. Even the commit "Fix
> inadequately-tested code path in tuplesort_skiptuples()." didn't add
> tests! There is scarcely any example of anyone deliberately adding
> test coverage to that file. I don't understand why it is so.
I don't know, either. You read both Robert and me indicating that this bug
fix will be better with a test, and nobody has said that a test-free fix is
optimal. Here's your chance to obliterate that no-tests precedent.
