Re: Can we automatically add elapsed times to tap test log?
От | Andrew Dunstan |
---|---|
Тема | Re: Can we automatically add elapsed times to tap test log? |
Дата | |
Msg-id | ef47999c-ecb7-6252-9893-1a39d9481499@dunslane.net обсуждение исходный текст |
Ответ на | Re: Can we automatically add elapsed times to tap test log? (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: Can we automatically add elapsed times to tap test log?
|
Список | 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
Вложения
В списке pgsql-hackers по дате отправления: