| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Magnus Hagander <magnus(at)hagander(dot)net> |
| Cc: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, David Rowley <dgrowleyml(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Recording test runtimes with the buildfarm |
| Date: | 2020-06-11 16:32:04 |
| Message-ID: | 345998.1591893124@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Magnus Hagander <magnus(at)hagander(dot)net> writes:
> On Thu, Jun 11, 2020 at 4:56 PM Andrew Dunstan <
> andrew(dot)dunstan(at)2ndquadrant(dot)com> wrote:
>> Yeah, we'll need to work out where to stash the file. The client will
>> pick up anything in src/regress/log for "make check", but would need
>> adjusting for other steps that invoke pg_regress. I'm getting close to
>> cutting a new client release, but I can delay it till we settle this.
> It seems pretty trivial to for example get all the steps out of check.log
> and their timing with a regexp.
Yeah, I don't see why we can't scrape this data from the existing
buildfarm output, at least for the core regression tests. New
infrastructure could make it easier/cheaper, but I don't think we
should invest in that until we've got a provably useful tool.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Magnus Hagander | 2020-06-11 16:48:46 | Re: Recording test runtimes with the buildfarm |
| Previous Message | Dilip Kumar | 2020-06-11 16:14:33 | Re: new heapcheck contrib module |