Re: Testing autovacuum wraparound (including failsafe)

From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
To: Alexander Lakhin <exclusion(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Testing autovacuum wraparound (including failsafe)
Date: 2024-10-10 06:25:24
Message-ID: CAD21AoBrcG1-YSJAtLmij1YqAULciS=WXTQEv4cODBEs1miZKQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Tue, Oct 8, 2024 at 10:00 PM Alexander Lakhin <exclusion(at)gmail(dot)com> wrote:
>
> Hello Masahiko-san,
>
> 01.12.2023 05:14, Masahiko Sawada wrote:
> > FYI I've configured the buildfarm animal perentie to run regression
> > tests including xid_wraparound:
> >
> > https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=perentie&br=HEAD
>
> Please look at a failure produced by perentie recently: [1].
>
> I've analyzed all the available detailed perentie logs (starting from
> 2024-04-04) and got the following durations of the pg_ctl stop operation
> at the end of the 001_emergency_vacuum.pl (from the
> module-xid_wraparound-check stage): see perentie-timings.txt and
> perentie-timings.png attached. So it looks like perentie needs larger
> PGCTLTIMEOUT for the test (maybe 180 seconds would work?).
>
> Though it's not clear to me, why this test takes so long on that animal,
> even when it succeeds. For example, [2] shows:
> [09:28:23] t/001_emergency_vacuum.pl .. ok 225894 ms ( 0.00 usr 0.00 sys + 0.31 cusr 0.43 csys = 0.74 CPU)
> [09:30:53] t/002_limits.pl ............ ok 150291 ms ( 0.00 usr 0.00 sys + 1.85 cusr 1.50 csys = 3.35 CPU)
> [09:49:33] t/003_wraparounds.pl ....... ok 1119766 ms ( 0.00 usr 0.00 sys + 1.68 cusr 2.39 csys = 4.07 CPU)
>
> While what I'm seeing locally on my Fedora 40 VM is:
> PG_TEST_EXTRA="xid_wraparound" make -s check -C src/test/modules/xid_wraparound/ PROVE_FLAGS="--timer"
> # +++ tap check in src/test/modules/xid_wraparound +++
> [04:41:56] t/001_emergency_vacuum.pl .. ok 18852 ms ( 0.01 usr 0.00 sys + 0.14 cusr 0.28 csys = 0.43 CPU)
> [04:42:15] t/002_limits.pl ............ ok 18539 ms ( 0.00 usr 0.00 sys + 0.72 cusr 0.88 csys = 1.60 CPU)
> [04:42:34] t/003_wraparounds.pl ....... ok 74368 ms ( 0.00 usr 0.00 sys + 0.82 cusr 2.57 csys = 3.39 CPU)

Thank you for reporting it.

I've investigated the logs you shared and figured out that some other
(personal) tests were overlapped at that time (perentie is my
machine). So the failure should be ignored, sorry for making noise.
I'll make sure other tests won't be overlapped again when perentie is
executing the regression tests.

> Also, maybe it would make sense to run this test for REL_17_STABLE too, as
> dodo is not with us since 2024-09-04, and I don't know if there are other
> animals running these tests (having xid_wraparound in PG_TEST_EXTRA).

Good idea. I've configured perentie to do that.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message jian he 2024-10-10 06:30:32 Re: not null constraints, again
Previous Message Kouber Saparev 2024-10-10 06:19:30 Re: BF mamba failure