Re: [HACKERS] A note about debugging TAP failures
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] A note about debugging TAP failures |
Дата | |
Msg-id | 32637.1492964037@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] A note about debugging TAP failures (Michael Banck <michael.banck@credativ.de>) |
Список | 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 по дате отправления: