On Wed, Jul 1, 2015 at 9:36 AM, Peter Geoghegan <pg@heroku.com> wrote:
> On Tue, Jun 30, 2015 at 5:25 PM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
>> Isn't this the kind of thing Coverty's supposed to find?
>
> I don't know, but in general I'm not very excited about static
> analysis tools. The best things that they have going for them is that
> they're available, and don't require test coverage in the same way as
> running the regression tests with Valgrind enabled.
Well, yes. It should have complained about that if it were a perfect
tool able to emulate all code paths with all possible variable values.
But Coverity is not actually that perfect, and sometimes it misses the
shot, like here. by experience when you look at reports of a static
tool, you need to have a look first at other code paths that share
similarities with the problem reported, and you will actually see that
most of the time what the static tool saw is just the tip of the
iceberg. The human factor is determinant in this case.
> There is no real testing of sorting in the regression tests. It would
> be nice to have a way of generating a large and varied selection of
> sort operations programmatically, to catch this kind of thing.
> pg_regress is not really up to it. The same applies to various other
> cases where having a lot of "expected" output makes using pg_regress
> infeasible.
Well, the issue is double here:
1) Having a buildfarm member with valgrind would greatly help.
2) This code path is not used at all AFAIK in the test suite, so we
definitely lack regression tests here. In your opinion what would be a
sort set large enough to be able to trigger this code path? The idea
is to not make the regression test suite take too much time because of
it, and not to have the server created by pg_regress running the
regression tests having a too large PGDATA folder. For example, could
a btree index do it with a correct data set do it on at least one
platform?
Regards,
--
Michael