Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wAL2E-002HfY-2H for pgsql-hackers@arkaria.postgresql.org; Wed, 08 Apr 2026 05:01:02 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wAL2D-004qki-0i for pgsql-hackers@arkaria.postgresql.org; Wed, 08 Apr 2026 05:01:01 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wAL2C-004qka-33 for pgsql-hackers@lists.postgresql.org; Wed, 08 Apr 2026 05:01:01 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wAL29-00000001F1E-1xtd for pgsql-hackers@lists.postgresql.org; Wed, 08 Apr 2026 05:01:01 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 63850pAT2996769; Wed, 8 Apr 2026 01:00:51 -0400 From: Tom Lane To: Andrew Dunstan cc: pgsql-hackers@lists.postgresql.org, Robert Haas Subject: BF client script runs src/test/modules TAP tests multiple times MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <2996737.1775624424.0@sss.pgh.pa.us> Date: Wed, 08 Apr 2026 01:00:51 -0400 Message-ID: <2996768.1775624451@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2996737.1775624424.1@sss.pgh.pa.us> I spent some more time poking into why my buildfarm animals seemed to have gotten markedly slower in the past month or so. One particular inflection point was the introduction of test_plan_advice. We knew that would be expensive, since it invokes an extra run of the core regression tests. On my animal indri, which can do install-check-C in about 10 or 11 seconds, you'd have expected that to add ten-ish seconds to the total cycle time. But it added more than 30 seconds. Investigation shows that what you'd guess from simple arithmetic is the truth: the BF client script is invoking that test *three times*. Once from make_misc_check, once from make_testmodules_install_check with locale "C", and once from make_testmodules_install_check with locale "en_US.utf8", since that animal is set up with locales => [ 'C', 'en_US.UTF-8' ], I do not think we need this. We should apply the same policy to src/test/modules as we do to contrib, namely that TAP tests are run just once during the "make check" phase, not during the "make installcheck" phases. I've applied the attached to my animals and it makes for a significant drop in cycle time. (I've not looked into whether the meson side has a similar issue.) regards, tom lane ------- =_aaaaaaaaaa0 Content-Type: text/x-diff; name="no-extra-tap-tests.patch"; charset="us-ascii" Content-ID: <2996737.1775624424.2@sss.pgh.pa.us> Content-Description: no-extra-tap-tests.patch Content-Transfer-Encoding: quoted-printable --- run_build.pl~ 2026-04-07 18:34:30.112991218 -0400 +++ run_build.pl 2026-04-07 22:33:56.230330171 -0400 @@ -2228,8 +2228,9 @@ sub make_testmodules_install_check my @checklog; unless ($using_msvc) { + # skip TAP tests - they are called elsewhere my $cmd =3D - "cd $pgsql/src/test/modules && $make USE_MODULE_DB=3D1 installcheck"; + "cd $pgsql/src/test/modules && $make USE_MODULE_DB=3D1 TAP_TESTS=3D i= nstallcheck"; @checklog =3D run_log($cmd); } else ------- =_aaaaaaaaaa0--