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  (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>)
Re: Test to dump and restore objects left behind by regression  (Peter Eisentraut <peter@eisentraut.org>)
Список 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 по дате отправления:

Предыдущее
От: James Coleman
Дата:
Сообщение: Re: RFC: Logging plan of the running query
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Speeding up COPY TO for uuids and arrays