|From:||Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>|
|To:||PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||pgbench tap tests & minor fixes|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
When developping new features for pgbench, I usually write some tests
which are lost when the feature is committed. Given that I have submitted
some more features and that part of pgbench code may be considered for
sharing with pgsql, I think that improving the abysmal state of tests
would be a good move.
The attached patch:
(1) extends the existing perl tap test infrastructure with methods to test
pgbench, i.e. "pgbench" which runs a pgbench test and "pgbench_likes"
which allows to check for expectations.
(2) reuse this infrastructure for the prior existing test about concurrent
(3) add a lot of new very small tests so that coverage jumps from very low
to over 90% for source files. I think that derived files (exprparse.c,
exprscan.c) should be removed from coverage analysis.
Previous coverage status:
exprparse.y 0.0 % 0 / 77 0.0 % 0 / 8
exprscan.l 0.0 % 0 / 102 0.0 % 0 / 8
pgbench.c 28.3 % 485 / 1716 43.1 % 28 / 65
exprparse.y 96.1 % 73 / 76 100.0 % 8 / 8
exprscan.l 92.8 % 90 / 97 100.0 % 8 / 8
pgbench.c 90.4 % 1542 / 1705 96.9 % 63 / 65
The test runtime is about doubled on my laptop, which is not too bad given
the coverage achieved.
(4) fixes a two minor issues. These fixes may be considered for
backpatching to 10, although I doubt anyone will complain, so I would not
- the -t/-R/-L combination was not working properly, fix that
by moving client statistics in processXactStats, adjust some
formula, and add a few comments for details I had to discover.
- add a check that --progress-timestamp => --progress
I'm unsure of the portability of some of the tests (\shell and \setshell),
especially on Windows. If there is an issue, these test will have to be
skipped on this platform.
Some of the tests may fail with a very low probability (eg 1/2**84?).
|Next Message||Kyotaro HORIGUCHI||2017-04-17 05:54:52||Re: Should pg_current_wal_location() become pg_current_wal_lsn()|
|Previous Message||Robert Haas||2017-04-17 05:46:28||Re: Shouldn't duplicate addition to publication be a no-op?|