Re: A note about debugging TAP failures

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: A note about debugging TAP failures
Date: 2017-04-22 22:48:42
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

> On 23 Apr 2017, at 00:06, Andres Freund <andres(at)anarazel(dot)de> 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_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.
> Because it means we'd still, by default, have to delete on
> failure. Otherwise you'd end up with an endless number of such partial
> directories. There's really no reason to do delete a failed directory
> ever, since the space usage is obviously bound.
> As there appears to be no benefit in the randomness of these
> directories, why work on retaining it?

I’ve never managed a buildfarm animal so there might be something there I’m
missing, but other than that I can’t see much reason (running concurrent make
check's in the same directory doesn’t seem useful). If one wants to keep a
directory around it’s easy enough to manually rename it.

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).

cheers ./daniel

Attachment Content-Type Size
tap_retaindir_v2.diff application/octet-stream 981 bytes

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Petr Jelinek 2017-04-22 23:10:32 Time based lag tracking for logical replication
Previous Message Andres Freund 2017-04-22 22:06:56 Re: A note about debugging TAP failures