Re: tuplesort test coverage

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Peter Geoghegan <pg@bowt.ie>, Heikki Linnakangas <heikki.linnakangas@iki.fi>, Robert Haas <robertmhaas@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2019-12-14T20:03:23Z
Lists: pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2019-12-12 09:27:04 -0500, Tom Lane wrote:
>> What seems like a simpler and more reliable fix is to make
>> test_mark_restore a temp table, thus keeping autovac away from it.
>> Is there a reason in terms of the test's goals not to do that?

> I can't see any reason. The sorting code shouldn't care about the source
> of tuples. I guess there could at some point be tests for parallel
> sorting, but that'd just use a different table.

OK, done that way.

>> Also ... why in the world does the script drop its tables at the end
>> with IF EXISTS?  They'd better exist at that point.  I object
>> to the DROP IF EXISTS up at the top, too.  The regression tests
>> do not need to be designed to deal with an unpredictable start state,
>> and coding them to do so can have no effect other than possibly
>> masking problems.

> Well, it makes it a heck of a lot easier to run tests in isolation while
> evolving them. While I personally think it's good to leave cleanup for
> partial states in for cases where it was helpful during development, I
> also don't care about it strongly.

As far as that goes, making the tables temp is an even better solution.

			regards, tom lane



Commits

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

  2. Remove unused code from tuplesort.

  3. Add tests for tuplesort.c.