Re: Test to dump and restore objects left behind by regression - Mailing list pgsql-hackers

From Ashutosh Bapat
Subject Re: Test to dump and restore objects left behind by regression
Date
Msg-id CAExHW5tS=7atyCg4Occ=JEU08vv8w6imR7jm85FLdKjePiTkbA@mail.gmail.com
Whole thread Raw
In response to Re: Test to dump and restore objects left behind by regression  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: Test to dump and restore objects left behind by regression
Re: Test to dump and restore objects left behind by regression
List 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



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Fix slot synchronization with two_phase decoding enabled
Next
From: torikoshia
Date:
Subject: Re: Change log level for notifying hot standby is waiting non-overflowed snapshot