Re: Test to dump and restore objects left behind by regression
Peter Eisentraut <peter@eisentraut.org>
From: Peter Eisentraut <peter@eisentraut.org>
To: Michael Paquier <michael@paquier.xyz>,
Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-02-22T09:16:50Z
Lists: pgsql-hackers
On 22.02.24 02:01, Michael Paquier wrote:
> 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.
The problem is, we don't really have any end-to-end coverage of
dump
restore
dump again
compare the two dumps
with a database with lots of interesting objects in it.
Note that each of these steps could fail.
We have somewhat relied on the pg_upgrade test to provide this testing,
but we have recently discovered that the dumps in binary-upgrade mode
are different enough to not test the normal dumps well.
Yes, this test is a bit expensive. We could save some time by doing the
first dump at the end of the normal regress test and have the pg_dump
test reuse that, but then that would make the regress test run a bit
longer. Is that a better tradeoff?
I have done some timing tests:
master:
pg_dump check: 22s
pg_dump check -j8: 8s
check-world -j8: 2min44s
patched:
pg_dump check: 34s
pg_dump check -j8: 13s
check-world -j8: 2min46s
So overall it doesn't seem that bad.
Commits
-
Hide expensive pg_upgrade test behind PG_TEST_EXTRA
- d185161e4739 18.0 landed
- 37fc1803cc12 19 (unreleased) landed
-
Set log_statement=none in t/002_pg_upgrade.pl
- 64fba9c61787 18.0 landed
-
002_pg_upgrade.pl: Move pg_dump test code for better stability
- 8806e4e8deb1 18.0 landed
-
002_pg_upgrade.pl: rename some variables for clarity
- abe56227b2e2 18.0 landed
-
Verify roundtrip dump/restore of regression database
- 172259afb563 18.0 landed
-
Refactor TAP test code for file comparisons into new routine in Utils.pm
- 169208092f5c 18.0 landed
-
Virtual generated columns
- 83ea6c54025b 18.0 cited
-
Put generated_stored test objects in a schema
- 894be11adfa6 18.0 cited
-
Introduce "builtin" collation provider.
- 2d819a08a1cb 17.0 cited
-
Revert "Improve compression and storage support with inheritance"
- 74563f6b9021 17.0 cited