From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Nathan Bossart <nathandbossart(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Can we automatically add elapsed times to tap test log? |
Date: | 2022-04-07 21:21:09 |
Message-ID: | 3472150.1649366469@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> On 4/2/22 06:57, Andrew Dunstan wrote:
>> Here's a version that actually works. It produces traces that look like
>> this:
>> andrew(at)emma:pg_upgrade $ grep '([0-9]*s)'
>> tmp_check/log/regress_log_002_pg_upgrade
>> [21:55:06](63s) ok 1 - dump before running pg_upgrade
>> [21:55:22](79s) ok 2 - run of pg_upgrade for new instance
>> [21:55:27](84s) ok 3 - old and new dumps match after pg_upgrade
>> [21:55:27](84s) 1..3
> I know there's a lot going on, but are people interested in this? It's a
> pretty small patch to produce something that seems quite useful.
I too think that the elapsed time is useful. I'm less convinced
that the time-of-day marker is useful.
It also seems kind of odd that the elapsed time accumulates rather
than being reset for each line. As it stands one would be doing a lot
of mental subtractions rather than being able to see directly how long
each step takes. I suppose that on fast machines where each step is
under one second, accumulation would be more useful than printing a
lot of zeroes --- but on the other hand, those aren't the cases where
you're going to be terribly concerned about the runtime.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Chapman Flack | 2022-04-07 21:37:38 | Re: trigger example for plsample |
Previous Message | chap | 2022-04-07 21:14:54 | Re: test/isolation/expected/stats_1.out broken for me |