Re: tuplesort test coverage
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Heikki Linnakangas <heikki.linnakangas@iki.fi>, Robert Haas <robertmhaas@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2019-11-14T00:25:46Z
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@anarazel.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
Commits
-
Try to stabilize results of new tuplesort regression test.
- baa32ce28b39 13.0 landed
-
Remove unused code from tuplesort.
- 7d962eaf50c0 13.0 landed
-
Add tests for tuplesort.c.
- 4a252996d5fd 13.0 landed