Re: Test to dump and restore objects left behind by regression
Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
From: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Peter Eisentraut <peter@eisentraut.org>,
Michael Paquier <michael@paquier.xyz>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-02-23T05:16:01Z
Lists: pgsql-hackers
On Thu, Feb 22, 2024 at 8:35 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Peter Eisentraut <peter@eisentraut.org> writes: > > 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. > > I'm very much against adding another full run of the core regression > tests to support this. This will be taken care of by Peter's latest idea of augmenting existing 002_pg_upgrade.pl. > But beyond the problem of not bloating the > check-world test runtime, there is the question of what this would > actually buy us. I doubt that it is worth very much, because > it would not detect bugs-of-omission in pg_dump. As I remarked in > the other thread, if pg_dump is blind to the existence of some > feature or field, testing that the dumps compare equal will fail > to reveal that it didn't restore that property. > > I'm not sure what we could do about that. One could imagine writing > some test infrastructure that dumps out the contents of the system > catalogs directly, and comparing that instead of pg_dump output. > But that'd be a lot of infrastructure to write and maintain ... > and it's not real clear why it wouldn't *also* suffer from > I-forgot-to-add-this hazards. If a developer forgets to add logic to dump objects that their patch adds, it's hard to detect it, through testing alone, in every possible case. We need reviewers to take care of that. I don't think that's the objective of this test case or of pg_upgrade test either. > > On balance, I think there are good reasons that we've not added > such a test, and I don't believe those tradeoffs have changed. > I am not aware of those reasons. Are they documented somewhere? Any pointers to the previous discussion on this topic? Googling "pg_dump regression pgsql-hackers" returns threads about performance regressions. On the flip side, the test I wrote reproduces the COMPRESSION/STORAGE bug you reported along with a few other bugs in that area which I will report soon on that thread. I think, that shows that we need such a test. -- Best Wishes, Ashutosh Bapat
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