Re: Test to dump and restore objects left behind by regression

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
Cc: Daniel Gustafsson <daniel(at)yesql(dot)se>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Michael Paquier <michael(at)paquier(dot)xyz>, vignesh C <vignesh21(at)gmail(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Test to dump and restore objects left behind by regression
Date: 2025-04-01 17:01:28
Message-ID: 202504011701.457wpmkb2tey@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2025-04-01 17:07:02 Re: macOS 15.4 versus strchrnul()
Previous Message Ashutosh Bapat 2025-04-01 16:58:25 Re: Reducing memory consumed by RestrictInfo list translations in partitionwise join planning