Re: SSI patch version 14

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>
Cc: "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "Markus Wanner" <markus(at)bluegap(dot)ch>, "Dan Ports" <drkp(at)csail(dot)mit(dot)edu>, "Pg Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SSI patch version 14
Date: 2011-01-27 15:44:32
Message-ID: 4D413E800200002500039E8B@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 of 56 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2011-01-27 15:53:23 Re: Re: In pg_test_fsync, use K(1024) rather than k(1000) for write size units.
Previous Message Robert Haas 2011-01-27 15:42:14 Re: ALTER TYPE 3: add facility to identify further no-work cases