|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
> 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.
|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|