Re: A note about debugging TAP failures

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: A note about debugging TAP failures
Date: 2017-04-22 21:05:13
Message-ID: 20170422210513.usq5ofawtuu6gjmu@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2017-04-22 16:22:59 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > On 2017-04-22 13:51:30 -0400, Tom Lane wrote:
> >> I think we need to fix TestLib and/or PostgresNode so that there's a way
> >> to make TAP tests not auto-clean their data directories at end of run,
> >> without having to resort to editing the script like this.
>
> > I think leaving the directory around in case of failures would be a
> > pretty bare minimum. It's sometimes also useful to keep the remains if
> > everything was apparently successfull, but it's far less important imo.
>
> 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.

> > To me it sounds like we shouldn't use a randomly generated temporary
> > name, but rather a static mapping based on the test's path or such, to
> > create the relevant temp directory. Before a start a test could then
> > clean that up, that way the amount of remaining cruft would be bound by
> > the number of tests.
>
> Yeah, that's a reasonable design. There doesn't seem to be a good reason
> to randomize the test directory names.

Just as long as they're unique across the tree, to allow for parallelism..

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2017-04-22 21:25:49 Re: A note about debugging TAP failures
Previous Message Andrew Dunstan 2017-04-22 20:43:33 recovery tests vs windows