From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <heikki(dot)linnakangas(at)iki(dot)fi>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: tuplesort test coverage |
Date: | 2019-11-14 00:25:46 |
Message-ID: | 20191114002546.a5fqvdmmkfpbir22@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2019-10-25 12:37:38 +0100, Peter Geoghegan wrote:
> On Thu, Oct 24, 2019 at 10:10 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > Here's a first stab at getting the coverage of tuplesort.c to a
> > satisfying level. There's still bits uncovered, but that's largely
> > either a) trace_sort related b) hopefully unreachable stuff c) explain
> > related. The largest actually missing thing is a disk-based
> > mark/restore, which probably ought be covered.
>
> Yeah. It looks like function coverage of logtape.c will be 100% once
> you have coverage of mark and restore.
Yea, it's definitely better after.
> > I think the the test time of this would still be OK, but if not we could
> > also work a bit more on that angle.
>
> That's hard for me to test right now, but offhand this general
> approach looks good to me. I am pretty sure it's portable.
I pushed this now. We'll see what the slower buildfarm animals say. I'll
try to see how long they took in a few days.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2019-11-14 00:46:31 | Re: Missing dependency tracking for TableFunc nodes |
Previous Message | Mark Dilger | 2019-11-13 23:00:03 | Re: Missing dependency tracking for TableFunc nodes |