From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Banck <michael(dot)banck(at)credativ(dot)de> |
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-23 16:13:57 |
Message-ID: | 32637.1492964037@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Michael Banck <michael(dot)banck(at)credativ(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-04-23 16:17:12 | Re: StandbyRecoverPreparedTransactions recovers subtrans links incorrectly |
Previous Message | Robert Haas | 2017-04-23 15:50:55 | Re: Removing select(2) based latch (was Unportable implementation of background worker start) |