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

From Craig Ringer
Subject Re: [HACKERS] A note about debugging TAP failures
Date
Msg-id CAMsr+YFyFU=+MVFZqhthfMW22x5-h517e6ck6ET+DT+X4bUO7g@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] A note about debugging TAP failures  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: [HACKERS] A note about debugging TAP failures  (Michael Paquier <michael.paquier@gmail.com>)
Re: [HACKERS] A note about debugging TAP failures  (Daniel Gustafsson <daniel@yesql.se>)
List pgsql-hackers


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.

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.

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.



There is a patch from Horiguchi-san that allows actually such a thing,
have a look at patch 0006 on this email:
https://www.postgresql.org/message-id/CAMsr+YEc2Ek=qJFJ2JeV7Spz69pOduoUJXBowZMppVYdeieRdA@mail.gmail.com

The same concept rebased gives the attached. I didn't double-check the
compatibility with past versions of Test:More though..
--
Michael


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


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: [HACKERS] Statistics "dependency"
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Statistics "dependency"