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

From: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Andres Freund <andres(at)anarazel(dot)de>, 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-04 11:11:51
Message-ID: CAExHW5vX+YLAKsEJT+fvwxmLxGAqDJST+3rqXqeUTjra29x2mA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Apr 3, 2025 at 10:44 PM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
>
> On 2025-Apr-03, Andres Freund wrote:
>
> > I've increased the timeout even further, but I can't say that I am happy about
> > the slowest test getting even slower. Adding test time in the serially slowest
> > test is way worse than adding the same time in a concurrent test.
>
> Yeah. We discussed strategies to shorten the runtime, but the agreement
> upthread was that we'd look for more elaborate ways to do that
> afterwards. As I mentioned, I can see adding something like
> PG_TEST_EXCLUDE that we could use to suppress this test on slow hosts.
> Would that work for you?
>
> (We also discussed the fact that this was part of 002_pg_upgrade.pl
> instead of being elsewhere. The reason is that this depends on the
> regression tests having run, and this is the only TAP test that does
> that. Well, this one and 027_stream_regress.pl which is even slower.)
>
> > I suspect that the test will go a bit faster if log_statement weren't forced
> > on, printing that many log lines, with context, does make valgrind slower,
> > IME. But Cluster.pm forces it to on, and I suspect that putting a global
> > log_statement=false into TEMP_CONFIG would have it's own disadvantages.
>
> I'm sure we can make this change as well somehow, overridding the
> setting just 002_pg_upgrade.pl, as attached. I don't think it's
> relevant for this particular test. The log files go from 21 MB to
> 2.4 MB. It's not nothing ...

It doesn't show any time improvement on my laptop, but it may improve
valgrind timing. My valgrind setup is broken, trying to fix it and run
it. I have included this as 0002 in the attached patchset.

0001 is an attempt to reduce runtime of the test by not setting up a
cluster for restoring the database. Instead the test uses the upgraded
node as the target. This works well since we expect the old node and
new node to be running the same version and default install. The only
unpleasantness is 1. dump and restore phases are spatially and
temporally separated 2. The upgraded regression database needs to be
renamed to save its state for diagnosis, if required. But as a result
this saves 3 seconds on my laptop. Earlier we saw that the test added
9 seconds on my laptop and we gained back 3 seconds; doesn't seem bad.
It will show a significant difference in valgrind run.

--
Best Wishes,
Ashutosh Bapat

Attachment Content-Type Size
0001-Reduce-time-taken-by-002_pg_upgrade-test-to-20250404.patch text/x-patch 5.9 KB
0002-Turn-off-log_statement-to-save-CPU-cycles-20250404.patch text/x-patch 1.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Bapat 2025-04-04 11:17:13 Re: Test to dump and restore objects left behind by regression
Previous Message Bertrand Drouvot 2025-04-04 10:57:55 Re: rename pg_log_standby_snapshot