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 по дате отправления: