Re: Buildfarm misses running some contrib TAP tests

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