Simon Riggs <si...@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
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
