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: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Daniel Gustafsson <daniel@yesql.se>, Tom Lane <tgl@sss.pgh.pa.us>, Michael Paquier <michael@paquier.xyz>, vignesh C <vignesh21@gmail.com>, Peter Eisentraut <peter@eisentraut.org>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-04-02T08:19:03Z
Lists: pgsql-hackers
On Tue, Apr 1, 2025 at 10:31 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote: > > On 2025-Apr-01, Ashutosh Bapat wrote: > > > Just today morning, I found something which looks like another bug in > > statistics dump/restore [1]. As Daniel has expressed upthread [2], we > > should go ahead and commit the test even if the bug is not fixed. But > > in case it creates a lot of noise and makes the build farm red, we > > could suppress the failure by not dumping statistics for comparison > > till the bug is fixed. PFA patchset which reintroduces 0003 which > > suppresses the statistics dump - in case we think it's needed. I have > > made some minor cosmetic changes to 0001 and 0002 as well. > > I have made some changes of my own, and included --no-statistics. > But I had already started messing with your patch, so I didn't look at > the cosmetic changes you did here. If they're still relevant, please > send them my way. Thanks a lot. I hope the test will now reveal the problems before they are committed :) You have edited those places anyway. So it's ok. I have closed the CF entry https://commitfest.postgresql.org/patch/4564/ committed. I will create another CF entry to park --no-statistics reversal change. That way, we will know when statistics dump/restore has become stable. > > Hopefully it won't break, and if it does, it's likely fault of the > changes I made. I've run it through CI and all is well though, so > fingers crossed. > https://cirrus-ci.com/build/6327169669922816 > > > I observe in the CI results that the pg_upgrade test is not necessarily > the last one to finish. In one case it even finished in place 12! > > [16:36:48.447] 12/332 postgresql:pg_upgrade / pg_upgrade/002_pg_upgrade OK 112.16s 22 subtests passed > https://api.cirrus-ci.com/v1/task/5803071017582592/logs/test_world.log Yes. Few animals that I sampled, the test is finishing pretty early even though it's taking longer than many other tests. But it's not the longest. I also looked at red animals, but none of them report this test to be failing. -- 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