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

  1. Try to stabilize results of new tuplesort regression test.

  2. Remove unused code from tuplesort.

  3. Add tests for tuplesort.c.