Content-Type: multipart/alternative;
 boundary="------------gH3YykWQam39laJHDPkS6FGP"
Message-ID: <20eef65a-b6df-4e22-be2a-6869a445fee7@dunslane.net>
Date: Wed, 8 Apr 2026 08:50:11 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Buildfarm misses running some contrib TAP tests
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@lists.postgresql.org
References: <2824159.1775603314@sss.pgh.pa.us>
 <2828027.1775605579@sss.pgh.pa.us>
From: Andrew Dunstan <andrew@dunslane.net>
Content-Language: en-US
Autocrypt: addr=andrew@dunslane.net; keydata=
 xsBNBE7KWFkBCAClridxur2AIc7eW2AR7izbfp3EnNefie2HbLF0izW5Ik5UjX2HBXBx4syI
 gY6b0ugohXrr274+baoAlvSbq6cAoQuEVrk5IZFzt20b1Xkx65FwGSEj526yiKLocqkJceSq
 Xr9xcA5SGY+FZv441chh5SU92v4q6z+6LPpoHOh97ptAVXZYNTtU0LevyvD5lja0TzbvJm6C
 eFXitJfnm1pLEr0DGJCR/iUOl/N62Kh4855zZC7NHIjQHPOvV5Stz/l5ilDhvGVk+xkXFPys
 SjZoUr1rXhYLpiyi5sR0X9FHXT0KnGuz1F5ERO7ZTLSSQ6fJwPj6gOk9K+vvoKvoeql5ABEB
 AAHNJEFuZHJldyBEdW5zdGFuIDxhbmRyZXdAZHVuc2xhbmUubmV0PsLAlwQTAQgAQQIbAwIX
 gAIZAQULCQgHAwUVCgkICwUWAgMBAAIeBRYhBOQ+WEYd/Hy/RGkVpZn6f8tZ/DuBBQJoGNGd
 BQkdEO8nAAoJEJn6f8tZ/DuBq74H/jkTR4Zi3stbw+xC7v2u3QozssK7MYPL2AsVfh7OealS
 h182fiWXpfvmmAB7WUHbhk9GC2RAOnHI/2d2jgKaMLAHsGYOT0YopTVIwRY43fCw/mK67yxc
 wmDcX+zyKfLaivNbf5A7QPLNwda98bEAMSJ8Sn652Uc6cA8t3uKGsVzbRBQOoYzjgvBCfSrE
 9ql3PDNg0l4BfAqabd2f70ZUm9VAMEPrgv/v2xI7M2XiL4g5BVmqLCOwxLM8RMCotCuoweUr
 VO43DeBCIDwLxotMJKvGWDjBzQYlU1NPUAtNcz/gN9ITUe1VUGjyvGj4u1lxBOcQQUw7l1+T
 5moZ4iZxXzvOwE0ETspYWQEIANGc4zQULOxhbqO2dyD51YhqCNRmm9oKWaqf+wmW4tpDe/VV
 cxAnNizd4LWCHfzpb5cHAtGkOPePMfzWVf6nvdF7d3eglbtf59+zG7O7llV0xSSoFiieQBsr
 GvqDInXYX/4mRRXMtyhM353/tixC9RWLs1oofyYmCPPXXY7h9R7en3B8BoVrRFcdzlIY/NFN
 hFGW/9dkEiGjgna2Rk6e15kln4ZvFBWUg23p93w/pqXcxY6+k/8TEk+C4R+M6w7o2PLGOjdZ
 +kPiUcw5H85zf/yZJwQXzisXaNduwWB6Vads9YC9dj6kPR1c4VGRqAaYL++LAEOqrlvm2Tvq
 QqZRtnEAEQEAAcLAfAQYAQgAJgIbDBYhBOQ+WEYd/Hy/RGkVpZn6f8tZ/DuBBQJoGNI2BQkd
 EODdAAoJEJn6f8tZ/DuBfw0IAKTsfD40teP/pp+bsLLMSxPXUYrrprTj7WFB5v61p6dkpSr/
 qXmMlyahdxQFaPmfVgVirB1Vk/kHiWNnnGjfUV9nB2Zg9LI0Xb9/ts3LsUiRWXzG3tkMY6XL
 vsVOxW4XFRND9l2q+WW93aZ1DZl+fqWfYgMvsusFRhmGFOKTRfKPta2Pkv+AhA24N4+PrR5p
 bU4k2MO8PAGiK8eaYKGFG1bHKuAvoDoF7WXJ3FHxuWqLnKEt4dfOLm5pAe3zq1Lt6q8azT9i
 QWGpSAK5vQUWQHBHpiDjdPeqKZ6HiAXIIKfSmb+jrvXBqoP+D6/K7rUjG2aXiRtTIAXms9sm
 VRu7cmw=
In-Reply-To: <2828027.1775605579@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/20eef65a-b6df-4e22-be2a-6869a445fee7%40dunslane.net>
Precedence: bulk

This is a multi-part message in MIME format.
--------------gH3YykWQam39laJHDPkS6FGP
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 2026-04-07 Tu 7:46 PM, Tom Lane wrote:
> 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.
>
> 			


Ugh. That's slightly embarrassing. So I guess the solution is not to use 
glob in scalar context here.

Will fix.


cheers


andrew

--
Andrew Dunstan
EDB:https://www.enterprisedb.com

--------------gH3YykWQam39laJHDPkS6FGP
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 2026-04-07 Tu 7:46 PM, Tom Lane
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:2828027.1775605579@sss.pgh.pa.us">
      <pre wrap="" class="moz-quote-pre">I wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">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.
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
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 = '&lt;undefined&gt;' 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 = &lt;undefined&gt;
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 = &lt;undefined&gt;
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 = &lt;undefined&gt;
examining /home/postgres/pgsql/contrib/sepgsql
sizeof glob = 0
scalar glob = &lt;undefined&gt;
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 = &lt;undefined&gt;

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.

			</pre>
    </blockquote>
    <p><br>
    </p>
    <p>Ugh. That's slightly embarrassing. So I guess the solution is not
      to use glob in scalar context here.</p>
    <p>Will fix.</p>
    <p><br>
    </p>
    <p>cheers</p>
    <p><br>
    </p>
    <p>andrew<br>
    </p>
    <p><span style="white-space: pre-wrap">
</span></p>
    <pre class="moz-signature"
    signature-switch-id="d0437855-2267-4610-80b3-83167ec45b0b" cols="72">--
Andrew Dunstan
EDB: <a class="moz-txt-link-freetext" href="https://www.enterprisedb.com">https://www.enterprisedb.com</a>
</pre>
  </body>
</html>

--------------gH3YykWQam39laJHDPkS6FGP--