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