Re: RFC: Additional Directory for Extensions

On 2025-03-21 Fr 12:42 PM, Tom Lane wrote:
> Matheus Alcantara<matheusssilv97(at)gmail(dot)com> writes:
>> On Thu, Mar 20, 2025 at 7:38 PM Andrew Dunstan<andrew(at)dunslane(dot)net> wrote:
>>>> (wondering if this another of these cases where the "path includes postgres" thing bites us, and we're looking in the wrong place)
>>> Nope, testing shows it's not that, so I am rather confused about what was going on.
>> I'm not sure if I'm checking on the right place [1] but it seems that the
>> Contrib and ContribInstall is executed after Check step which causes this test
>> failure?
> No, this is not failing in Check.
>
> I did just notice a clue though: on snakefly, the failing step's
> log [1] includes
>
> make[1]: Leaving directory `/opt/postgres/build-farm-18/HEAD/pgsql.build/src/backend'
> rm -rf '/opt/postgres/build-farm-18/HEAD/pgsql.build'/tmp_install
> /usr/bin/mkdir -p '/opt/postgres/build-farm-18/HEAD/pgsql.build'/tmp_install/log
> make -C '../../../..' DESTDIR='/opt/postgres/build-farm-18/HEAD/pgsql.build'/tmp_install install >'/opt/postgres/build-farm-18/HEAD/pgsql.build'/tmp_install/log/install.log 2>&1
> make -j1 checkprep >>'/opt/postgres/build-farm-18/HEAD/pgsql.build'/tmp_install/log/install.log 2>&1
> PATH="/opt/postgres/build-farm-18/HEAD/pgsql.build/tmp_install/opt/postgres/build-farm-18/HEAD/inst/bin:/opt/postgres/build-farm-18/HEAD/pgsql.build/src/test/modules/test_extensions:$PATH" LD_LIBRARY_PATH="/opt/postgres/build-farm-18/HEAD/pgsql.build/tmp_install/opt/postgres/build-farm-18/HEAD/inst/lib:$LD_LIBRARY_PATH" INITDB_TEMPLATE='/opt/postgres/build-farm-18/HEAD/pgsql.build'/tmp_install/initdb-template initdb --auth trust --no-sync --no-instructions --lc-messages=C --no-clean '/opt/postgres/build-farm-18/HEAD/pgsql.build'/tmp_install/initdb-template >>'/opt/postgres/build-farm-18/HEAD/pgsql.build'/tmp_install/log/initdb-template.log 2>&1
> echo "# +++ regress check in src/test/modules/test_extensions +++" && PATH="/opt/postgres/build-farm-18/HEAD/pgsql.build/tmp_install/opt/postgres/build-farm-18/HEAD/inst/bin:/opt/postgres/build-farm-18/HEAD/pgsql.build/src/test/modules/test_extensions:$PATH" LD_LIBRARY_PATH="/opt/postgres/build-farm-18/HEAD/pgsql.build/tmp_install/opt/postgres/build-farm-18/HEAD/inst/lib:$LD_LIBRARY_PATH" INITDB_TEMPLATE='/opt/postgres/build-farm-18/HEAD/pgsql.build'/tmp_install/initdb-template ../../../../src/test/regress/pg_regress --temp-instance=./tmp_check --inputdir=. --bindir= --temp-config=/opt/postgres/build-farm-18/tmp/buildfarm-C9Iy3s/bfextra.conf --no-locale --port=5678 --dbname=contrib_regression test_extensions test_extdepend
> # +++ regress check in src/test/modules/test_extensions +++
> # initializing database system by running initdb
>
> showing that the step made its own tmp_install, and that only the core
> "install" process was executed, so the lack of amcheck in that install
> tree is not surprising. But concurrent runs on other animals, eg [2],
> don't show a tmp_install rebuild happening. So those are using an
> installation tree that *does* include contrib modules.
>
> So what this comes down to is "why is snakefly doing a fresh install
> here?". I don't know the buildfarm client well enough to identify
> probable causes. I do note that Makefile.global.in conditionalizes
> tmp_install rebuild on several variables:
>
> temp-install: | submake-generated-headers
> ifndef NO_TEMP_INSTALL
> ifneq ($(abs_top_builddir),)
> ifeq ($(MAKELEVEL),0)
> rm -rf '$(abs_top_builddir)'/tmp_install
> $(MKDIR_P) '$(abs_top_builddir)'/tmp_install/log
> $(MAKE) -C '$(top_builddir)' DESTDIR='$(abs_top_builddir)'/tmp_install install >'$(abs_top_builddir)'/tmp_install/log/install.log 2>&1
> $(MAKE) -j1 $(if $(CHECKPREP_TOP),-C $(CHECKPREP_TOP),) checkprep >>'$(abs_top_builddir)'/tmp_install/log/install.log 2>&1

Good catch. This is happening because the owner hasn't updated the
animal to REL_19_1. In 19 and 19.1 we fixed detection of exiting
installs to take account of the 'Is there postgres or pgsql in the
prefix' issue. So it was looking in the wrong place.

cheers

andrew

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