Re: SSI patch version 14

Kevin Grittner <kevin.grittner@wicourts.gov>

From: "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
To: "Simon Riggs" <simon@2ndQuadrant.com>, "Dan Ports" <drkp@csail.mit.edu>
Cc: <pgsql-hackers@postgresql.org>
Date: 2011-01-26T16:01:28Z
Lists: pgsql-hackers
Simon Riggs <simon@2ndQuadrant.com> wrote:
> On Wed, 2011-01-26 at 11:36 +0000, Simon Riggs wrote:
> 
>> Pounding for hours on 16 CPU box sounds good. What diagnostics or
>> instrumentation are included with the patch? How will we know
>> whether pounding for hours is actually touching all relevant
>> parts of code? I've done such things myself only to later realise
>> I wasn't actually testing the right piece of code.
> 
> An example of this is the XIDCACHE_DEBUG code used in procarray.c
> to validate TransactionIdIsInProgress().
 
It isn't exactly equivalent, but on a conceptually similar note some
of the hours of DBT-2 pounding were done with #ifdef statements to
force code into code paths which are normally rarely used.  We left
one of them in the codebase with the #define commented out, although
I know that's not strictly necessary.  (It does provide a convenient
place to put a comment about what it's for, though.)
 
In looking at it just now, I noticed that after trying it in a
couple different places what was left in the repository was not the
optimal version for code coverage.  I've put this back to the
version which did a better job, for reasons described in the commit
comment:
 
http://git.postgresql.org/gitweb?p=users/kgrittn/postgres.git;a=commitdiff;h=8af1bc84318923ba0ec3d4413f374a3beb10bc70
 
Dan, did you have some others which should maybe be included?
 
I'm not sure I see any counts we could get from SSI which would be
useful beyond what we might get from a code coverage tool or
profiling, but I'm open to suggestions.
 
-Kevin