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.
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
... but if we still find that it's too slow, we can make it into a
PG_TEST_EXTRA test easily with a "skip" line. (Or we can add
a new PG_TEST_EXCLUDE thingy for impatient people).
Thanks!
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
