Re: Test to dump and restore objects left behind by regression - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Test to dump and restore objects left behind by regression
Date
Msg-id ZdadA7RD0Oyc36_-@paquier.xyz
Whole thread Raw
In response to Test to dump and restore objects left behind by regression  (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>)
Responses Re: Test to dump and restore objects left behind by regression
Re: Test to dump and restore objects left behind by regression
List 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

Attachment

pgsql-hackers by date:

Previous
From: James Coleman
Date:
Subject: Re: RFC: Logging plan of the running query
Next
From: Michael Paquier
Date:
Subject: Re: Speeding up COPY TO for uuids and arrays