Re: Test to dump and restore objects left behind by regression
| От | Michael Paquier |
|---|---|
| Тема | Re: Test to dump and restore objects left behind by regression |
| Дата | |
| Msg-id | ZdadA7RD0Oyc36_-@paquier.xyz обсуждение исходный текст |
| Ответ на | Test to dump and restore objects left behind by regression (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>) |
| Ответы |
Re: Test to dump and restore objects left behind by regression
Re: Test to dump and restore objects left behind by regression |
| Список | 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
Вложения
В списке pgsql-hackers по дате отправления: