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 <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1wAG7l-002DJx-0L
	for pgsql-hackers@arkaria.postgresql.org;
	Tue, 07 Apr 2026 23:46:25 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.96)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1wAG7j-003IGB-1s
	for pgsql-hackers@arkaria.postgresql.org;
	Tue, 07 Apr 2026 23:46:23 +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 <tgl@sss.pgh.pa.us>)
	id 1wAG7j-003IG2-10
	for pgsql-hackers@lists.postgresql.org;
	Tue, 07 Apr 2026 23:46:23 +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 <tgl@sss.pgh.pa.us>)
	id 1wAG7h-00000001Cci-1e4s
	for pgsql-hackers@lists.postgresql.org;
	Tue, 07 Apr 2026 23:46:23 +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 637NkJX72828028;
	Tue, 7 Apr 2026 19:46:19 -0400
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew@dunslane.net>
cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Buildfarm misses running some contrib TAP tests
In-reply-to: <2824159.1775603314@sss.pgh.pa.us>
References: <2824159.1775603314@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Tue, 07 Apr 2026 19:08:34 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2828026.1775605579.1@sss.pgh.pa.us>
Date: Tue, 07 Apr 2026 19:46:19 -0400
Message-ID: <2828027.1775605579@sss.pgh.pa.us>
List-Id: <pgsql-hackers.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-hackers@lists.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-hackers>
Archived-At: 
 <https://www.postgresql.org/message-id/2828027.1775605579%40sss.pgh.pa.us>
Precedence: bulk

I wrote:
> 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.

Oh ... apparently, what it thinks that means is that successive
calls will return file names out of the previous "scalar glob"
call, until it finally returns undef, and then the next call
starts a new scan.  This simple test program:

use strict;
use warnings;

my $pgsql = '/home/postgres/pgsql';

	foreach my $testdir (glob("$pgsql/contrib/*"))
	{
		next unless -d "$testdir/t";
		print "examining $testdir\n";

		my @gresult = glob("$testdir/*.o $testdir/*.obj");
		print 'sizeof glob = ' . scalar @gresult . "\n";

		# can't test it if we haven't built it
		my $scal = scalar glob("$testdir/*.o $testdir/*.obj");
		$scal = '<undefined>' if not defined($scal);
		print 'scalar glob = ' . $scal . "\n";
	}

1;

gives me

examining /home/postgres/pgsql/contrib/amcheck
sizeof glob = 4
scalar glob = /home/postgres/pgsql/contrib/amcheck/verify_common.o
examining /home/postgres/pgsql/contrib/auto_explain
sizeof glob = 1
scalar glob = /home/postgres/pgsql/contrib/amcheck/verify_gin.o
examining /home/postgres/pgsql/contrib/basebackup_to_shell
sizeof glob = 1
scalar glob = /home/postgres/pgsql/contrib/amcheck/verify_heapam.o
examining /home/postgres/pgsql/contrib/bloom
sizeof glob = 6
scalar glob = /home/postgres/pgsql/contrib/amcheck/verify_nbtree.o
examining /home/postgres/pgsql/contrib/dblink
sizeof glob = 1
scalar glob = <undefined>
examining /home/postgres/pgsql/contrib/oid2name
sizeof glob = 1
scalar glob = /home/postgres/pgsql/contrib/oid2name/oid2name.o
examining /home/postgres/pgsql/contrib/pg_prewarm
sizeof glob = 2
scalar glob = <undefined>
examining /home/postgres/pgsql/contrib/pg_stash_advice
sizeof glob = 3
scalar glob = /home/postgres/pgsql/contrib/pg_stash_advice/pg_stash_advice.o
examining /home/postgres/pgsql/contrib/pg_stat_statements
sizeof glob = 1
scalar glob = /home/postgres/pgsql/contrib/pg_stash_advice/stashfuncs.o
examining /home/postgres/pgsql/contrib/pg_visibility
sizeof glob = 1
scalar glob = /home/postgres/pgsql/contrib/pg_stash_advice/stashpersist.o
examining /home/postgres/pgsql/contrib/postgres_fdw
sizeof glob = 5
scalar glob = <undefined>
examining /home/postgres/pgsql/contrib/sepgsql
sizeof glob = 0
scalar glob = <undefined>
examining /home/postgres/pgsql/contrib/test_decoding
sizeof glob = 1
scalar glob = /home/postgres/pgsql/contrib/test_decoding/test_decoding.o
examining /home/postgres/pgsql/contrib/vacuumlo
sizeof glob = 1
scalar glob = <undefined>

So we are getting results that depend mainly on how many .o files
there were in some previous contrib directory.  That explains how
come pg_stash_advice managed to change the behavior of later
modules.

			regards, tom lane