Peter Eisentraut wrote:
> On 1/19/18 14:07, David Steele wrote:
> > I have yet to add tests for pg_rewindwal and pg_upgrade. pg_rewindwal
> > doesn't *have* any tests as far as I can tell and pg_upgrade has tests
> > in a shell script -- it's not clear how I would extend it or reuse the
> > Perl code for perm testing.
> >
> > Does anyone have suggestions on tests for pg_resetwal and pg_upgrade?
> > Should I start from scratch?
>
> A test suite for pg_resetwal would be nice.
>
> TAP tests for pg_upgrade will create problems with the build farm.
> There was a recent thread about that.
Is this about this commit?
commit 58ffe141eb37c3f027acd25c1fc6b36513bf9380
Author: Peter Eisentraut <peter_e@gmx.net>
AuthorDate: Fri Sep 22 16:34:46 2017 -0400
CommitDate: Fri Sep 22 16:46:56 2017 -0400
Revert "Add basic TAP test setup for pg_upgrade"
This reverts commit f41e56c76e39f02bef7ba002c9de03d62b76de4d.
The build farm client would run the pg_upgrade tests twice, once as part
of the existing pg_upgrade check run and once as part of picking up all
TAP tests by looking for "t" directories. Since the pg_upgrade tests
are pretty slow, we will need a better solution or possibly a build farm
client change before we can proceed with this.
If the only problem is that buildfarm would run tests twice, then I
think we should just press forward with this regardless of that: it
seems a chicken-and-egg problem, because buildfarm cannot be upgraded to
use some new test method if the method doesn't exist yet. As a
solution, let's just live with some run duplication for a period until
the machines are upgraded to a future buildfarm client code.
If there are other problems, let's see what they are so that we can fix
them.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services