Re: [HACKERS] A note about debugging TAP failures - Mailing list pgsql-hackers

From Daniel Gustafsson
Subject Re: [HACKERS] A note about debugging TAP failures
Date
Msg-id 33587C7E-92E0-441F-8824-B04DB9CC67DE@yesql.se
Whole thread Raw
In response to Re: [HACKERS] A note about debugging TAP failures  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] A note about debugging TAP failures  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
> On 22 Apr 2017, at 23:25, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Andres Freund <andres@anarazel.de> 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
>>> will never be a need to override their judgment.
>
>> 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 directories.
>
> Mm, not convinced.  I think that the delete-on-success behavior was
> intentional, to limit the amount of disk space a buildfarm member would
> consume during a run.  I don't mind that being the default, as long as
> there's a way to override it manually.

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
example which gives a decent clue to what was executed.  To allow for
retain-on-success, checking for an environment variable in the cleanup phase
seems the simplest approach.

cheers ./daniel


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [HACKERS] A note about debugging TAP failures
Next
From: Andres Freund
Date:
Subject: Re: [HACKERS] A note about debugging TAP failures