Re: A note about debugging TAP failures

On Sun, Apr 23, 2017 at 10:05 PM, Craig Ringer
<craig(dot)ringer(at)2ndquadrant(dot)com> wrote:
> On 23 Apr. 2017 10:32, "Michael Paquier" <michael(dot)paquier(at)gmail(dot)com> wrote:
> On Sun, Apr 23, 2017 at 7:48 AM, Daniel Gustafsson <daniel(at)yesql(dot)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