Re: Can we automatically add elapsed times to tap test log? - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: Can we automatically add elapsed times to tap test log?
Date
Msg-id ef47999c-ecb7-6252-9893-1a39d9481499@dunslane.net
Whole thread Raw
In response to Re: Can we automatically add elapsed times to tap test log?  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: Can we automatically add elapsed times to tap test log?  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
On 4/1/22 16:25, Andrew Dunstan wrote:
> On 4/1/22 15:16, Andrew Dunstan wrote:
>> On 4/1/22 13:44, Nathan Bossart wrote:
>>> On Fri, Apr 01, 2022 at 10:21:50AM -0700, Andres Freund wrote:
>>>> right now I am looking at a test added in the shmstats patch that's slow on
>>>> CI, on windows only. Unfortunately the regress_log_* output is useless as-is
>>>> to figure out where things hang.
>>>>
>>>> I've hit this several times before. Of course it's not too hard to hack up
>>>> something printing elapsed time. But ISTM that it'd be better if we were able
>>>> to prefix the logging into regress_log_* with something like
>>>> [timestamp + time since start of test]
>>>> or
>>>> [timestamp + time since start of test + time since last log message]
>>>>
>>>>
>>>> This isn't just useful to figure out what parts of test are slow, but also
>>>> helps correlate server logs with the regress_log_* output. Which right now is
>>>> hard and inaccurate, requiring manually correlating statements between server
>>>> log and the tap test (often there's no logging for statements in the
>>>> regress_log_*).
>>> +1
>>>
>> Maybe one way would be to make a change in
>> src/test/perl/PostgreSQL/Test/SimpleTee.pm. The simplest thing would
>> just be to add a timestamp, the other things would involve a bit more
>> bookkeeping. It should also be checked to make sure it doesn't add too
>> much overhead, although I would be surprised if it did.
>>
>
> Along these lines. Untested, it clearly needs a bit of polish (e.g. a
> way to turn it on or off for a filehandle). We could use Time::Hires if
> you want higher resolution times.
>
>


Here's a version that actually works. It produces traces that look like
this:


andrew@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


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

Attachment

pgsql-hackers by date:

Previous
From: Julien Rouhaud
Date:
Subject: Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements
Next
From: Andrei Zubkov
Date:
Subject: Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements