Re: A note about debugging TAP failures

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

> On 22 Apr 2017, at 23:25, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Andres Freund <andres(at)anarazel(dot)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

Attachment Content-Type Size
tap_retaindir.diff application/octet-stream 1.0 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2017-04-22 22:06:56 Re: A note about debugging TAP failures
Previous Message Andres Freund 2017-04-22 21:35:09 Re: A note about debugging TAP failures