Re: [HACKERS] Inadequate traces in TAP tests

On 20 March 2017 at 22:39, Alvaro Herrera wrote: > Stephen Frost wrote: > >> Is there any hope of getting a "quiet" mode, where all the "ok" lines >> aren't printed when things work..? > > Well, we currently have --verbose in PROVE_FLAGS. Maybe you can take it > out, or

Re: [HACKERS] Inadequate traces in TAP tests

Andrew, * Andrew Dunstan (andrew.duns...@2ndquadrant.com) wrote: > On 03/20/2017 10:25 AM, Craig Ringer wrote: > > I'd like to enable Carp's features to use confess for traces, and > > switch all use of die to that. We could learn a lot about > > unplanned-for test failures where a test script

Re: [HACKERS] Inadequate traces in TAP tests

On 03/20/2017 10:25 AM, Craig Ringer wrote: > > > I'd like to enable Carp's features to use confess for traces, and > switch all use of die to that. We could learn a lot about > unplanned-for test failures where a test script dies rather than > failing a test if we used carp effectively. > > >

Re: [HACKERS] Inadequate traces in TAP tests

Alvaro, * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > Stephen Frost wrote: > > Is there any hope of getting a "quiet" mode, where all the "ok" lines > > aren't printed when things work..? > > Well, we currently have --verbose in PROVE_FLAGS. Maybe you can take it > out, or even add

Re: [HACKERS] Inadequate traces in TAP tests

Stephen Frost wrote: > Is there any hope of getting a "quiet" mode, where all the "ok" lines > aren't printed when things work..? Well, we currently have --verbose in PROVE_FLAGS. Maybe you can take it out, or even add --quiet or --QUIET (see the prove(1) manpage). -- Álvaro Herrera

Re: [HACKERS] Inadequate traces in TAP tests

Alvaro, * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > Stephen Frost wrote: > > * Andrew Dunstan (andrew.duns...@2ndquadrant.com) wrote: > > > ISTM that the test setup and breakdown code, both in individual tests > > > and in PostgresNode.pm should be liberally sprinkled with diag() calls

Re: [HACKERS] Inadequate traces in TAP tests

On 03/20/2017 10:08 AM, Tom Lane wrote: > I am *absolutely* not in favor of adding anything to the scripts' routine > output, because it will just make this problem worse by bloating the > buildfarm logs even more. What I'd like to see is for the scripts to > always report something along the

Re: [HACKERS] Inadequate traces in TAP tests

On 20 Mar. 2017 22:10, "Tom Lane" wrote: FWIW, the problem I've got with the TAP tests is that when one fails in the buildfarm, you've got to dig through megabytes of all-alike-looking output just to try to determine which one failed; and once you do, you still know nothing

Re: [HACKERS] Inadequate traces in TAP tests

Stephen Frost wrote: > Andrew, > * Andrew Dunstan (andrew.duns...@2ndquadrant.com) wrote: > > ISTM that the test setup and breakdown code, both in individual tests > > and in PostgresNode.pm should be liberally sprinkled with diag() calls > > to make it easier to narrow down errors.. > > While

Re: [HACKERS] Inadequate traces in TAP tests

Stephen Frost writes: > * Andrew Dunstan (andrew.duns...@2ndquadrant.com) wrote: >> ISTM that the test setup and breakdown code, both in individual tests >> and in PostgresNode.pm should be liberally sprinkled with diag() calls >> to make it easier to narrow down errors.. >

Re: [HACKERS] Inadequate traces in TAP tests

Andrew, * Andrew Dunstan (andrew.duns...@2ndquadrant.com) wrote: > If you look at this failure case > > you see: > > t/002_pg_dump.1..4449 > # Looks like your test died before it could

[HACKERS] Inadequate traces in TAP tests

If you look at this failure case you see: t/002_pg_dump.1..4449 # Looks like your test died before it could output anything. dubious Test returned status 255 (wstat 65280,