Re: scalability bottlenecks with (many) partitions (and more) - Mailing list pgsql-hackers

From Andres Freund
Subject Re: scalability bottlenecks with (many) partitions (and more)
Date
Msg-id qdvrgej743lcddjnb4lzyakt3f5bs2oz34r274wbmgc2g4474q@utqqrqiih65h
Whole thread Raw
In response to Re: scalability bottlenecks with (many) partitions (and more)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: scalability bottlenecks with (many) partitions (and more)
List pgsql-hackers
Hi,

On 2025-03-04 16:30:34 -0500, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2025-03-04 19:58:38 +0100, Tomas Vondra wrote:
> >> I noticed sifaka started failing right after I pushed this:
>
> > It's worth noting that
> > a) sifaka doesn't build with ldap support
> > b) the failure is in checkprep, not when running the tests
> > c) the buildfarm unfortunately doesn't archive install.log, so it's hard to
> >    know what actually went wrong
>
> Yeah, I've been poking at that.  It's not at all clear why the
> animal is trying to run src/test/modules/ldap_password_func
> now when it didn't before.

It did do so before as well, afaict:

https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=sifaka&dt=2025-03-04%2015%3A01%3A42&stg=module-ldap_password_func-check

It seems to me that the difference is that now checkprep is run, whereas
previously it wasn't.

Before:
/Library/Developer/CommandLineTools/usr/bin/make -C adt jsonpath_gram.h
make[3]: `jsonpath_gram.h' is up to date.
echo "# +++ tap check in src/test/modules/ldap_password_func +++" && rm -rf
'/Users/buildfarm/bf-data/HEAD/pgsql.build/src/test/modules/ldap_password_func'/tmp_check&& /bin/sh
../../../../config/install-sh-c -d
'/Users/buildfarm/bf-data/HEAD/pgsql.build/src/test/modules/ldap_password_func'/tmp_check&& cd . &&
TESTLOGDIR='/Users/buildfarm/bf-data/HEAD/pgsql.build/src/test/modules/ldap_password_func/tmp_check/log'
TESTDATADIR='/Users/buildfarm/bf-data/HEAD/pgsql.build/src/test/modules/ldap_password_func/tmp_check'
PATH="/Users/buildfarm/bf-data/HEAD/pgsql.build/tmp_install/Users/buildfarm/bf-data/HEAD/inst/bin:/Users/buildfarm/bf-data/HEAD/pgsql.build/src/test/modules/ldap_password_func:$PATH"
DYLD_LIBRARY_PATH="/Users/buildfarm/bf-data/HEAD/pgsql.build/tmp_install/Users/buildfarm/bf-data/HEAD/inst/lib:$DYLD_LIBRARY_PATH"
INITDB_TEMPLATE='/Users/buildfarm/bf-data/HEAD/pgsql.build'/tmp_install/initdb-template PGPORT='65678'
top_builddir='/Users/buildfarm/bf-data/HEAD/pgsql.build/src/test/modules/ldap_password_func/../../../..'
PG_REGRESS='/Users/buildfarm/bf-data/HEAD/pgsql.build/src/test/modules/ldap_password_func/../../../../src/test/regress/pg_regress'
share_contrib_dir='/Users/buildfarm/bf-data/HEAD/pgsql.build/tmp_install/Users/buildfarm/bf-data/HEAD/inst/share/postgresql/contrib'
/usr/bin/prove-I ../../../../src/test/perl/ -I . --timer t/*.pl 
# +++ tap check in src/test/modules/ldap_password_func +++
[10:08:59] t/001_mutated_bindpasswd.pl .. skipped: LDAP not supported by this build
[10:08:59]

Now:
/Library/Developer/CommandLineTools/usr/bin/make -C adt jsonpath_gram.h
make[3]: `jsonpath_gram.h' is up to date.
rm -rf '/Users/buildfarm/bf-data/HEAD/pgsql.build'/tmp_install
/bin/sh ../../../../config/install-sh -c -d '/Users/buildfarm/bf-data/HEAD/pgsql.build'/tmp_install/log
/Library/Developer/CommandLineTools/usr/bin/make -C '../../../..'
DESTDIR='/Users/buildfarm/bf-data/HEAD/pgsql.build'/tmp_installinstall
>'/Users/buildfarm/bf-data/HEAD/pgsql.build'/tmp_install/log/install.log2>&1 
/Library/Developer/CommandLineTools/usr/bin/make -j1  checkprep
>>'/Users/buildfarm/bf-data/HEAD/pgsql.build'/tmp_install/log/install.log2>&1 
make: *** [temp-install] Error 2
log files for step module-ldap_password_funcCheck:


Note during a normal build ldap_password_func shouldn't be entered:
# Test runs an LDAP server, so only run if ldap is in PG_TEST_EXTRA
ifeq ($(with_ldap),yes)
ifneq (,$(filter ldap,$(PG_TEST_EXTRA)))
SUBDIRS += ldap_password_func
else
ALWAYS_SUBDIRS += ldap_password_func
endif
else
ALWAYS_SUBDIRS += ldap_password_func
endif


Which leads me to suspect that the difference might be related to
NO_TEMP_INSTALL not being set while it previously was. Which then triggers the
module being built, whereas it previously wasn't.

Of course relying on NO_TEMP_INSTALL preventing this from being built isn't
exactly reliable...


Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Jacob Brazeal
Date:
Subject: Re: Next commitfest app release is planned for March 18th
Next
From: Tom Lane
Date:
Subject: Re: bogus error message for ALTER TABLE ALTER CONSTRAINT