Re: tap tests remove working directories - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: tap tests remove working directories
Date
Msg-id 55C53C7B.9000208@dunslane.net
Whole thread Raw
In response to Re: tap tests remove working directories  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: tap tests remove working directories  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 08/07/2015 05:11 PM, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> One of the things that makes the TAP tests very difficult and annoying
>> to debug is their insistence on removing their data directories. I'm not
>> sure why they are doing that. We don't do that with pg_regress. Instead
>> we have clean targets to remove them if necessary. I suggest that we
>> either disable that altogether, and provide cleanup make targets, or at
>> least make it optional, say by setting an environment variable, say
>> TMP_CLEANUP or some such. There is probably a good case for defaulting
>> that to off, but I could live with it being on.
> I thought we'd decided awhile ago that best practice would be to
> auto-remove temp directories only on success.  Is that a workable
> behavior for you, or are you concerned about being able to poke
> around even after the test thinks it succeeded?
>
>             

That certainly isn't what happens, and given the way this is done in 
TestLib.pm, using the CLEANUP parameter of File::Temp's tempdir() 
function, it's not clear how we could do that easily. The deletion 
behaviour is set when you create the directory, not afterwards. What I 
suggested could be done with a couple of lines of code.

I could probably live with your suggestion, especially if I could change 
the behaviour easily. But what we have now is quite frustrating. I have 
to hack the source just to be able to diagnose an error. That's really 
pretty unacceptable.

cheers

andrew



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: WIP: SCRAM authentication
Next
From: Andres Freund
Date:
Subject: Re: Reduce ProcArrayLock contention