Re: Reporting script runtimes in pg_regress

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Reporting script runtimes in pg_regress
Дата
Msg-id 20190212020941.GC1475@paquier.xyz
обсуждение исходный текст
Ответ на Re: Reporting script runtimes in pg_regress  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Список pgsql-hackers
On Tue, Feb 12, 2019 at 10:29:40AM +0900, Amit Langote wrote:
> On 2019/02/11 23:30, Tom Lane wrote:
>> Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
>>> Now that I see this in action, it makes the actual test results harder
>>> to identify flying by.  I understand the desire to collect this timing
>>> data, but that is a special use case and not relevant to the normal use
>>> of the test suite, which is to see whether the test passes.  Can we make
>>> this optional please?
>>
>> Well, I want the buildfarm to produce this info, so it's hard to see
>> how to get that without the timings being included by default.  I take
>> your point that it makes the display look a bit cluttered, though.
>> Would it help to put more whitespace between the status and the timing?
>
> +1.  Maybe, not as much whitespace as we get today between the test name
> and "... ok", but at least more than just a single space.

Sure, but do we need feedback immediately?  I am just catching up on
that, and I too find a bit annoying that this is not controlled by a
switch which is disabled by default.  It seems to me that this points
out to another issue that there is no actual way to pass down custom
options to pg_regress other than PG_REGRESS_DIFF_OPTS to control the
diff output format.  So we may also want something like
PG_REGRESS_OPTS.
--
Michael

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: Protect syscache from bloating with negative cache entries
Следующее
От: Justin Pryzby
Дата:
Сообщение: Re: pg11.1: dsa_area could not attach to segment