Re: RFC: Additional Directory for Extensions - Mailing list pgsql-hackers
From | Andrew Dunstan |
---|---|
Subject | Re: RFC: Additional Directory for Extensions |
Date | |
Msg-id | 30e7d162-408d-4d35-aa6a-1591d012b623@dunslane.net Whole thread Raw |
In response to | Re: RFC: Additional Directory for Extensions (Tom Lane <tgl@sss.pgh.pa.us>) |
List | pgsql-hackers |
On 2025-03-21 Fr 12:42 PM, Tom Lane wrote:
Matheus Alcantara <matheusssilv97@gmail.com> writes:On Thu, Mar 20, 2025 at 7:38 PM Andrew Dunstan <andrew@dunslane.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
pgsql-hackers by date: