I wrote:
> While the overall code coverage for PostgreSQL source code is:
>
> Overall coverage rate:
> lines......: 64.8% (130296 of 201140 lines)
> functions..: 72.0% (7997 of 11109 functions)
By the way, I discovered that the above is lower if you just run the
check target. The dcheck target helps with overall PostgreSQL code
coverage, even though it was targeted at the SSI code.
> The coverage for predicate.c, after running both check and dcheck,
> was (formatted to match above):
>
> lines......: 69.8% (925 of 1325 lines)
> functions..: 85.7% (48 of 56 functions)
Some minor tweaks to the regression tests boosts that to: lines......: 73.1% (968 of 1325 lines) functions..: 89.3% (50
of56 functions)
Most of the code not covered in the regular build (above) is in the
OldSerXidXxxxx functions, which are covered well in a build with
TEST_OLDSERXID defined. The 2PC code is very well covered now,
except for the recovery-time function. We don't have a way to test
that in the `make check` process, do we?
There is some code which is not covered just because it is so hard
to hit -- for example, code which is only executed if vacuum cleans
up an index page when we are right at the edge of running out of the
memory used to track predicate locks. It would be hard to include a
test for that in the normal regression tests.
The regression test changes are here:
http://git.postgresql.org/gitweb?p=users/kgrittn/postgres.git;a=commitdiff;h=d4c1005d731c81049cc2622e50b7a2ebb99bbcac
-Kevin