Re: [HACKERS] A note about debugging TAP failures - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] A note about debugging TAP failures
Date
Msg-id 32637.1492964037@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] A note about debugging TAP failures  (Michael Banck <michael.banck@credativ.de>)
List pgsql-hackers
Michael Banck <michael.banck@credativ.de> writes:
> On Sat, Apr 22, 2017 at 02:05:13PM -0700, Andres Freund wrote:
>> 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.

> In general yes, but I think it should be checked what the overall 
> storage requirements will be if one set of all data directories is kept
> around.

> I was surprised the src/bin/pg_basebackup/t TAP tests took up several
> hundred megabytes (IIRC) when I ran them, so if other tests are similar,
> it might make a few animals run out of diskspace as soon as this is
> deployed without a heads-up to the operators.

src/test/recovery/ alone eats 2.6GB if one sets CLEANUP => 0 as I did
upthread.  So I think leaving them there by default is a nonstarter.
It might be okay to leave failed tests' dirs in place, but even there,
I'd personally prefer a manual control knob.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] Removing select(2) based latch (was Unportableimplementation of background worker start)
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] StandbyRecoverPreparedTransactions recovers subtrans links incorrectly