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

From Michael Paquier
Subject Re: [HACKERS] A note about debugging TAP failures
Date
Msg-id CAB7nPqSCuuiKuAk-_LiNaNcaNBLaCvcUXFG_Ci8kyFNDncy+dw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] A note about debugging TAP failures  (Craig Ringer <craig.ringer@2ndquadrant.com>)
List pgsql-hackers
On Sun, Apr 23, 2017 at 10:05 PM, Craig Ringer
<craig.ringer@2ndquadrant.com> wrote:
> On 23 Apr. 2017 10:32, "Michael Paquier" <michael.paquier@gmail.com> wrote:
> On Sun, Apr 23, 2017 at 7:48 AM, Daniel Gustafsson <daniel@yesql.se> 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
>> overridden) but that logic can easily be turned around if we want that.
>> If
>> it’s of interest I can pursue this after some sleep (tomorrow has become
>> today
>> at this point).
>
> Yes, something like that may make sense as well for readability.
>
> 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
> :(
>
> Huh? We do keep test temp datadirs etc in case of failure. Just not on
> success.

Yes, you are right. I thought this was not the case. Happy to be wrong.

> Our definition of failure there sucks a bit though. We keep the datadirs if
> any test fails in a script. If the script its self crashes we still blow
> away the datadirs which is kind of counterintuitive.

Yes, I agree that it would make sense to keep them around in this case
as well, having the data folder may help in debugging tests in some
cases.

> I'd like to change the __DIE__ sig handler to only delete on clean script
> exit code, tap reporting success, and if some env bar like PG_TESTS_NOCLEAN
> is undefined. The later could also be used in pg_regress etc.

This looks like a sensible plan.
--
Michael



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: [HACKERS] pg_dump emits ALTER TABLE ONLY partitioned_table
Next
From: Andres Freund
Date:
Subject: Re: [HACKERS] walsender & parallelism