Re: [HACKERS] A note about debugging TAP failures

2017-09-05 Thread Daniel Gustafsson
> On 05 Sep 2017, at 18:37, Peter Eisentraut > wrote: > > On 4/25/17 11:00, Daniel Gustafsson wrote: >> Makes sense, assuming a “clean slate” to run on seems a reasonable assumption >> for the test and it makes for simpler code in PostgresNode. Updated the >> patch >> which now have static dat

Re: [HACKERS] A note about debugging TAP failures

2017-09-05 Thread Peter Eisentraut
On 4/25/17 11:00, Daniel Gustafsson wrote: > Makes sense, assuming a “clean slate” to run on seems a reasonable assumption > for the test and it makes for simpler code in PostgresNode. Updated the patch > which now have static datadir names; retains on PG_TESTS_NOCLEAN or any kind > of > test fai

Re: [HACKERS] A note about debugging TAP failures

2017-04-25 Thread Daniel Gustafsson
> On 24 Apr 2017, at 17:19, Craig Ringer wrote: > > On 24 April 2017 at 20:01, Daniel Gustafsson wrote: > >> I’m np Perl expert though so there might be better/cleaner ways to achieve >> this, in testing it seems to work though. rmtree() is supported at least >> since >> Perl 5.6 from what I

Re: [HACKERS] A note about debugging TAP failures

2017-04-24 Thread Craig Ringer
On 24 April 2017 at 20:01, Daniel Gustafsson wrote: > I’m np Perl expert though so there might be better/cleaner ways to achieve > this, in testing it seems to work though. rmtree() is supported at least > since > Perl 5.6 from what I can see. I'd rather just have the 'make' target nuke the re

Re: [HACKERS] A note about debugging TAP failures

2017-04-24 Thread Daniel Gustafsson
> On 23 Apr 2017, at 15:05, Craig Ringer wrote: > > On 23 Apr. 2017 10:32, "Michael Paquier" > wrote: > On Sun, Apr 23, 2017 at 7:48 AM, Daniel Gustafsson > wrote: > > Skipping the tempdir and instead using ${testname}_data_${name} witho

Re: [HACKERS] A note about debugging TAP failures

2017-04-23 Thread Andres Freund
On 2017-04-23 11:31:05 +0900, Michael Paquier wrote: > Keeping folders in case of failures is something that I have been > advocating in favor of for some time, but this never got into the tree > :( I don't think it'd be ok to do so unless you the randomness of dirnames is changed as you'd just ac

Re: [HACKERS] A note about debugging TAP failures

2017-04-23 Thread Michael Paquier
On Sun, Apr 23, 2017 at 10:05 PM, Craig Ringer wrote: > On 23 Apr. 2017 10:32, "Michael Paquier" wrote: > On Sun, Apr 23, 2017 at 7:48 AM, Daniel Gustafsson wrote: >> Skipping the tempdir and instead using ${testname}_data_${name} without a >> random suffix, we can achieve this with something al

Re: [HACKERS] A note about debugging TAP failures

2017-04-23 Thread Tom Lane
Michael Banck writes: > On Sat, Apr 22, 2017 at 02:05:13PM -0700, Andres Freund wrote: >> Agreed. If paths are reproducible and cleaned up on next run it's also >> much less of an issue to just leave them around till the next run. >> Which we imo also should do for non-failing tmp_check directori

Re: [HACKERS] A note about debugging TAP failures

2017-04-23 Thread Craig Ringer
On 23 Apr. 2017 10:32, "Michael Paquier" wrote: On Sun, Apr 23, 2017 at 7:48 AM, Daniel Gustafsson wrote: > Skipping the tempdir and instead using ${testname}_data_${name} without a > random suffix, we can achieve this with something along the lines of the > attached PoC. It works as now (retai

Re: [HACKERS] A note about debugging TAP failures

2017-04-23 Thread Michael Banck
On Sat, Apr 22, 2017 at 02:05:13PM -0700, Andres Freund wrote: > On 2017-04-22 16:22:59 -0400, Tom Lane wrote: > > Andres Freund writes: > > > On 2017-04-22 13:51:30 -0400, Tom Lane wrote: > > >> I think we need to fix TestLib and/or PostgresNode so that there's a way > > >> to make TAP tests not

Re: [HACKERS] A note about debugging TAP failures

2017-04-22 Thread Michael Paquier
On Sun, Apr 23, 2017 at 7:48 AM, Daniel Gustafsson wrote: > Skipping the tempdir and instead using ${testname}_data_${name} without a > random suffix, we can achieve this with something along the lines of the > attached PoC. It works as now (retain of failure, remove on success unless > overridde

Re: [HACKERS] A note about debugging TAP failures

2017-04-22 Thread Daniel Gustafsson
> On 23 Apr 2017, at 00:06, Andres Freund wrote: > > On 2017-04-22 23:59:11 +0200, Daniel Gustafsson wrote: >> Since we have the name of the running testscript, can’t we just add that to >> the >> tempdir to make the name more descriptive? With the attached patch I get >> tmp_check/001_pgbench_

Re: [HACKERS] A note about debugging TAP failures

2017-04-22 Thread Andres Freund
On 2017-04-22 23:59:11 +0200, Daniel Gustafsson wrote: > Since we have the name of the running testscript, can’t we just add that to > the > tempdir to make the name more descriptive? With the attached patch I get > tmp_check/001_pgbench_data_main_ItEm when running tests in src/bin/pgbench for >

Re: [HACKERS] A note about debugging TAP failures

2017-04-22 Thread Daniel Gustafsson
> On 22 Apr 2017, at 23:25, Tom Lane wrote: > > Andres Freund writes: >> On 2017-04-22 16:22:59 -0400, Tom Lane wrote: >>> In the particular case I was interested in here, the test script thought >>> everything was successful :-(. I'm working on fixing that little problem, >>> but I do not beli

Re: [HACKERS] A note about debugging TAP failures

2017-04-22 Thread Andres Freund
On 2017-04-22 17:25:49 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2017-04-22 16:22:59 -0400, Tom Lane wrote: > >> In the particular case I was interested in here, the test script thought > >> everything was successful :-(. I'm working on fixing that little problem, > >> but I do not be

Re: [HACKERS] A note about debugging TAP failures

2017-04-22 Thread Tom Lane
Andres Freund writes: > On 2017-04-22 16:22:59 -0400, Tom Lane wrote: >> In the particular case I was interested in here, the test script thought >> everything was successful :-(. I'm working on fixing that little problem, >> but I do not believe that the TAP scripts are so bulletproof that there

Re: [HACKERS] A note about debugging TAP failures

2017-04-22 Thread Andres Freund
On 2017-04-22 16:22:59 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2017-04-22 13:51:30 -0400, Tom Lane wrote: > >> I think we need to fix TestLib and/or PostgresNode so that there's a way > >> to make TAP tests not auto-clean their data directories at end of run, > >> without having to r

Re: [HACKERS] A note about debugging TAP failures

2017-04-22 Thread Tom Lane
Andres Freund writes: > On 2017-04-22 13:51:30 -0400, Tom Lane wrote: >> I think we need to fix TestLib and/or PostgresNode so that there's a way >> to make TAP tests not auto-clean their data directories at end of run, >> without having to resort to editing the script like this. > I think leavin

Re: [HACKERS] A note about debugging TAP failures

2017-04-22 Thread Andres Freund
Hi, On 2017-04-22 13:51:30 -0400, Tom Lane wrote: > I think we need to fix TestLib and/or PostgresNode so that there's a way > to make TAP tests not auto-clean their data directories at end of run, > without having to resort to editing the script like this. I think leaving the directory around in

Re: [HACKERS] A note about debugging TAP failures

2017-04-22 Thread Fabien COELHO
I think we need to fix TestLib and/or PostgresNode so that there's a way to make TAP tests not auto-clean their data directories at end of run, without having to resort to editing the script like this. It'd also be helpful if the data directory pathname included the test script's name. Rely o

[HACKERS] A note about debugging TAP failures

2017-04-22 Thread Tom Lane
I've whined before about how developer-unfriendly the TAP test infrastructure is. One concrete problem is that if there is a failure, there is absolutely no way to get any information beyond what is in the logs, because the test installation's data directory is unconditionally blown away at run en