Re: Another usability issue with our TAP tests

2018-07-17 Thread Michael Paquier
On Tue, Jul 17, 2018 at 03:02:32PM -0400, Tom Lane wrote: > Cute idea, but it seems not to work with older versions of prove: > > $ which prove > /usr/local/perl5.8.3/bin/prove > $ prove --state=save > Unknown option: s I didn't know this one, and that's actually nice, but I cannot get easily a w

Re: Another usability issue with our TAP tests

2018-07-17 Thread Tom Lane
Peter Eisentraut writes: > How about something like this: > -PG_PROVE_FLAGS = -I $(top_srcdir)/src/test/perl/ -I $(srcdir) > +PG_PROVE_FLAGS = -I $(top_srcdir)/src/test/perl/ -I $(srcdir) --state=save Cute idea, but it seems not to work with older versions of prove: $ which prove /usr/local/per

Re: Another usability issue with our TAP tests

2018-07-17 Thread Peter Eisentraut
On 16.07.18 19:13, Tom Lane wrote: > But a TAP test failure leaves nothing behind that git will consider > unusual. I've repeatedly had to run check-world with no parallelism > (wasting many minutes) in order to locate which test actually failed. How about something like this: diff --git a/src/M

Re: Another usability issue with our TAP tests

2018-07-17 Thread Michael Paquier
On Mon, Jul 16, 2018 at 01:13:36PM -0400, Tom Lane wrote: > Since "make check-world" is rather chatty, if you get a failure while > running it under high parallelism, the location of the failure has often > scrolled off the terminal window by the time all the other subjobs > exit. Yes, I have pest

Another usability issue with our TAP tests

2018-07-16 Thread Tom Lane
Since "make check-world" is rather chatty, if you get a failure while running it under high parallelism, the location of the failure has often scrolled off the terminal window by the time all the other subjobs exit. This is not a huge problem for tests using our traditional infrastructure, because