I wrote:
> Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
>> Is there a convenient way to compare two coverage runs?
> Hmm ... diff'ing the html output is really painful, but it
> looks like using checktcp instead of check causes 48 lines
> in ecpg to change from not-covered to covered.
Enlarging on that a little: the coverage in src/interfaces/ecpg
changes from
11860/(11860+12555.) = 0.48577
to
11908/(11908+12507.) = 0.48773
Meanwhile, the coverage in src/interfaces/libpq changes from
2421/(2421+4488.) = 0.35041
to
2481/(2481+4428.) = 0.35910
and the whole-system coverage from
256632/(256632+163564.) = 0.61074
to
256839/(256839+163357.) = 0.61124
This is comparing coverage reports for the core regression tests
plus ecpg "make check" versus core plus ecpg "make checktcp".
The increase in coverage outside ecpg is presumably because
we otherwise aren't hitting TCP-socket code paths at all,
while Unix-socket code is covered in both cases. So it's only
fair to include the non-ecpg coverage increase as a benefit
if you suppose that no other tests will hit the TCP code paths.
That might well have been true awhile ago, but I think that the
SSL and Kerberos tests are now covering much of that territory
(if coverage.postgresql.org is running those?)
regards, tom lane
