Horton

Re: tuplesort test coverage

Peter Geoghegan <pg@bowt.ie>

View thread View on postgr.es
From: Peter Geoghegan <pg@bowt.ie>
To: Andres Freund <andres@anarazel.de>
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-10-25T11:37:38Z
Lists: pgsql-hackers 
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.

> 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.

-- 
Peter Geoghegan

Commits

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

  2. Remove unused code from tuplesort.

  3. Add tests for tuplesort.c.