Horton

Re: Test to dump and restore objects left behind by regression

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Peter Eisentraut <peter@eisentraut.org>
Date: 2024-02-22T01:01:55Z
Lists: pgsql-hackers 
On Wed, Feb 21, 2024 at 12:18:45PM +0530, Ashutosh Bapat wrote:
> Even with 1 and 2 the test is useful to detect dump/restore anomalies.
> I think we should improve 3, but I don't have a good and simpler
> solution. I didn't find any way to compare two given clusters in our
> TAP test framework. Building it will be a lot of work. Not sure if
> it's worth it.

+	my $rc =
+	  system($ENV{PG_REGRESS}
+		  . " $extra_opts "
+		  . "--dlpath=\"$dlpath\" "
+		  . "--bindir= "
+		  . "--host="
+		  . $node->host . " "
+		  . "--port="
+		  . $node->port . " "
+		  . "--schedule=$srcdir/src/test/regress/parallel_schedule "
+		  . "--max-concurrent-tests=20 "
+		  . "--inputdir=\"$inputdir\" "
+		  . "--outputdir=\"$outputdir\"");

I am not sure that it is a good idea to add a full regression test
cycle while we have already 027_stream_regress.pl that would be enough
to test some dump scenarios.  These are very expensive and easy to
notice even with a high level of parallelization of the tests.
--
Michael

Commits

  1. Hide expensive pg_upgrade test behind PG_TEST_EXTRA

  2. Set log_statement=none in t/002_pg_upgrade.pl

  3. 002_pg_upgrade.pl: Move pg_dump test code for better stability

  4. 002_pg_upgrade.pl: rename some variables for clarity

  5. Verify roundtrip dump/restore of regression database

  6. Refactor TAP test code for file comparisons into new routine in Utils.pm

  7. Virtual generated columns

  8. Put generated_stored test objects in a schema

  9. Introduce "builtin" collation provider.

  10. Revert "Improve compression and storage support with inheritance"