Re: Test to dump and restore objects left behind by regression
Alvaro Herrera <alvherre@alvh.no-ip.org>
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Cc: vignesh C <vignesh21@gmail.com>, Michael Paquier <michael@paquier.xyz>, Daniel Gustafsson <daniel@yesql.se>, Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter@eisentraut.org>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-03-24T12:14:55Z
Lists: pgsql-hackers
On 2025-Mar-24, Ashutosh Bapat wrote: > One concern I have with directory format is the dumped database is not > readable. This might make investigating a but identified the test a > bit more complex. Oh, it's readable all right. You just need to use `pg_restore -f-` to read it. No big deal. So I ran this a few times: /usr/bin/time make -j8 -Otarget -C /pgsql/build/master check-world -s PROVE_FLAGS="-c -j6" > /dev/null commenting out the call to test_regression_dump_restore() to test how much additional runtime does the new test incur. With test: 136.95user 116.56system 1:13.23elapsed 346%CPU (0avgtext+0avgdata 250704maxresident)k 4928inputs+55333008outputs (114major+14784937minor)pagefaults 0swaps 138.11user 117.43system 1:15.54elapsed 338%CPU (0avgtext+0avgdata 278592maxresident)k 48inputs+55333464outputs (80major+14794494minor)pagefaults 0swaps 137.05user 113.13system 1:08.19elapsed 366%CPU (0avgtext+0avgdata 279272maxresident)k 48inputs+55330064outputs (83major+14758028minor)pagefaults 0swaps without the new test: 135.46user 114.55system 1:14.69elapsed 334%CPU (0avgtext+0avgdata 145372maxresident)k 32inputs+55155256outputs (105major+14737549minor)pagefaults 0swaps 135.48user 114.57system 1:09.60elapsed 359%CPU (0avgtext+0avgdata 148224maxresident)k 16inputs+55155432outputs (95major+14749502minor)pagefaults 0swaps 133.76user 113.26system 1:14.92elapsed 329%CPU (0avgtext+0avgdata 148064maxresident)k 48inputs+55154952outputs (84major+14749531minor)pagefaults 0swaps 134.06user 113.83system 1:16.09elapsed 325%CPU (0avgtext+0avgdata 145940maxresident)k 32inputs+55155032outputs (83major+14738602minor)pagefaults 0swaps The increase in duration here is less than a second. My conclusion with these numbers is that it's not worth hiding this test in PG_TEST_EXTRA. If we really wanted to save some total test runtime, it might be better to write a regress schedule file for 027_stream_regress.pl which only takes the test that emit useful WAL, rather than all tests. -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ "The ability of users to misuse tools is, of course, legendary" (David Steele) https://postgr.es/m/11b38a96-6ded-4668-b772-40f992132797@pgmasters.net
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