public inbox for [email protected]  
help / color / mirror / Atom feed
From: Tom Lane <[email protected]>
To: Andrew Dunstan <[email protected]>
Cc: [email protected]
Subject: Buildfarm misses running some contrib TAP tests
Date: Tue, 07 Apr 2026 19:08:34 -0400
Message-ID: <[email protected]> (raw)

I noticed by accident that my buildfarm animal indri stopped running
certain contrib TAP tests this morning.  In [1] it's running

contrib-amcheck-check (00:00:12)
contrib-auto_explain-check (00:00:02)
contrib-basebackup_to_shell-check (00:00:01)
contrib-bloom-check (00:00:05)
contrib-oid2name-check (00:00:01)
contrib-pg_stat_statements-check (00:00:02)
contrib-postgres_fdw-check (00:00:07)
contrib-test_decoding-check (00:00:07)
contrib-vacuumlo-check (00:00:01)

but in the very next run [2] we see

contrib-amcheck-check (00:00:12)
contrib-auto_explain-check (00:00:01)
contrib-basebackup_to_shell-check (00:00:02)
contrib-bloom-check (00:00:05)
contrib-oid2name-check (00:00:00)
contrib-pg_stash_advice-check (00:00:03)
contrib-pg_stat_statements-check (00:00:02)
contrib-pg_visibility-check (00:00:03)
contrib-test_decoding-check (00:00:08)

What became of postgres_fdw and vacuumlo?  And why wasn't
pg_visibility being run before?  And why are dblink and pg_prewarm
visible in neither list?  Apparently the addition of pg_stash_advice
changed something here, but what?

Looking at some other BF animals shows that it's not just indri: other
autoconf-based animals are showing misbehavior of this sort as well.

I poked at this by adding some debug printouts, and determined that
what is going wrong is the test to see if we built the module:

		# can't test it if we haven't built it
		next unless scalar glob("$testdir/*.o $testdir/*.obj");

It's failing, sometimes, on modules that definitely do contain object
files.  We've had run-ins with "scalar glob()" before [3], and when
I finally looked at "man perlfunc" what I read is

       glob EXPR
       glob
           In list context, returns a (possibly empty) list of filename
           expansions on the value of EXPR such as the standard Unix shell
           /bin/csh would do.  In scalar context, glob iterates through such
           filename expansions, returning undef when the list is exhausted.

I'm not entirely sure what "iterates" means in this context, but
what seems to be happening on my Linux box is that you get undef
unless there is exactly one file matching the glob pattern.

I can't explain why we're not seeing more consistent behavior
out of the buildfarm, like never running postgres_fdw at all.
I wonder if the glob() infrastructure has some buggy internal state.
But the attached patch gives me better results.

			regards, tom lane

[1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=indri&dt=2026-04-07%2013%3A42%3A46
[2] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=indri&dt=2026-04-07%2014%3A17%3A01
[3] https://www.postgresql.org/message-id/200085.1741127335%40sss.pgh.pa.us



Attachments:

  [text/x-diff] misctests.patch (440B, 2-misctests.patch)
  download | inline diff:
--- run_build.pl.orig	2025-11-25 07:47:25.000000000 -0500
+++ run_build.pl	2026-04-07 18:34:30.112991218 -0400
@@ -2511,7 +2511,8 @@ sub run_misc_tests
 		my $testname = basename($testdir);
 
 		# can't test it if we haven't built it
-		next unless scalar glob("$testdir/*.o $testdir/*.obj");
+		my @objfiles = glob("$testdir/*.o $testdir/*.obj");
+		next unless scalar @objfiles;
 
 		# skip sepgsql unless it's marked for testing
 		next


view thread (3+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: Buildfarm misses running some contrib TAP tests
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox