Content-Type: multipart/alternative;
 boundary="------------xBvjfl3RW4a8S5RbleFQecuj"
Message-ID: <30e7d162-408d-4d35-aa6a-1591d012b623@dunslane.net>
Date: Sat, 22 Mar 2025 09:28:41 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: RFC: Additional Directory for Extensions
To: Tom Lane <tgl@sss.pgh.pa.us>, Matheus Alcantara
 <matheusssilv97@gmail.com>, tharar@amazon.com
Cc: Peter Eisentraut <peter@eisentraut.org>,
 Gabriele Bartolini <gabriele.bartolini@enterprisedb.com>,
 Craig Ringer <craig.ringer@enterprisedb.com>,
 "David E. Wheeler" <david@justatheory.com>,
 Robert Haas <robertmhaas@gmail.com>, Alvaro Herrera
 <alvherre@alvh.no-ip.org>,
 PostgreSQL-development <pgsql-hackers@postgresql.org>
References: 
 <CA+TgmoaMk==vOUmWwJ5ZA-EueNqa9RQaWMEiHCF1ZKW_YCcj8g@mail.gmail.com>
 <4f7209ba-1ca2-475e-9a70-0f3fe0be6378@eisentraut.org>
 <CAFY6G8dzuLXFjONX5E-TvyD5E9r21b5vp1My_nMcqdGD0VYfYw@mail.gmail.com>
 <12312928-5516-49b8-81c1-a7b56fd01bc8@dunslane.net>
 <CAFY6G8dGcv1D8tCkjrz+9DvAYG9h4U=hBm0VXjJEXExy44hauQ@mail.gmail.com>
 <CAFY6G8eOMkGXLqzUz=qXrwt4X_HvmVZ13570DAbgAiw+3q03DA@mail.gmail.com>
 <CAFY6G8fV5FTqn7p8pxbvPYUD5+ffik-J50GChjKH2Gg7d=fRPg@mail.gmail.com>
 <38c53446-6b65-4222-b76b-351e56f4841c@eisentraut.org>
 <CAFY6G8cGeUV0f5K8v-Du0ts3iZyRE6Q5dNtYjQq8cjS4epLX5A@mail.gmail.com>
 <7c178ff3-20a5-493e-a704-e6b3263e782f@eisentraut.org>
 <CAFY6G8d56BK5TZ7K+uw4DHLZ=9Th3p+E1x4pp26nJ_K5k4EUwA@mail.gmail.com>
 <784527.1742410558@sss.pgh.pa.us>
 <feb169e1-a43e-48ff-95eb-807cae713056@dunslane.net>
 <ffbd66a4-0567-44e6-86ed-b817509207eb@dunslane.net>
 <CAFY6G8eqwzdA=-L276izfq1jbPpjeDK! RZW5oNs9j4DY5n7M=8Q@mail.gmail.com>
 <1571161.1742575348@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
 AAHNJEFuZHJldyBEdW5zdGFuIDxhbmRyZXdAZHVuc2xhbmUubmV0PsLAmwQTAQgARQIbAwIX
 gAIZAQULCQgHAgMiAgEGFQoJCAsCBBYCAwECHgcWIQTkPlhGHfx8v0RpFaWZ+n/LWfw7gQUC
 ZFlxxwUJGVGAbgAKCRCZ+n/LWfw7gXikB/9ZdcUy6CTBFIIuL/bVsc1eLEW/gJBjJBF6HxNY
 xgEkAgXAp4Lg4A5U+QB9GouFr7+GYxF0BU4hzoGhNPUWltxnHdMWP8nC/38LAqgMi8L/bbsm
 HW5YPBdWYaAZAPJQVfOAgjTbRUb26KSprpyrrJKW0ZmrZfjhNPcQ72jpWzoPLQqx2X6B0fru
 1jq+cBh8lb6r1mJTim1T3JIn+F/v5VpdQS+EL8xqsHkfzKjIPsW3CIXpkypSk6saA55Rkkbl
 26AW8ftPVB0Q6Lnn6FLt9CP0MGNixBQ55yq8r1K+nCBvCCjvQjM8RDm0UUum0WNl+ifQgTLO
 E8TWEnwVtkBf+3QWzsBNBE7KWFkBCADRnOM0FCzsYW6jtncg+dWIagjUZpvaClmqn/sJluLa
 Q3v1VXMQJzYs3eC1gh386W+XBwLRpDj3jzH81lX+p73Re3d3oJW7X+ffsxuzu5ZVdMUkqBYo
 nkAbKxr6gyJ12F/+JkUVzLcoTN+d/7YsQvUVi7NaKH8mJgjz112O4fUe3p9wfAaFa0RXHc5S
 GPzRTYRRlv/XZBIho4J2tkZOnteZJZ+GbxQVlINt6fd8P6al3MWOvpP/ExJPguEfjOsO6Njy
 xjo3WfpD4lHMOR/Oc3/8mScEF84rF2jXbsFgelWnbPWAvXY+pD0dXOFRkagGmC/viwBDqq5b
 5tk76kKmUbZxABEBAAHCwHwEGAEIACYCGwwWIQTkPlhGHfx8v0RpFaWZ+n/LWfw7gQUCZFlx
 5wUJGVGAjgAKCRCZ+n/LWfw7gf+iB/4g8CPY5jihf5r/8EsoIGe2H+dpVmpPF8YGBzTIvCz/
 fQoOq8AX/pE76QEuFnFZWfjw+wgBXgCVmkox2Eflkk6z4ND3pcwGZ6CfCxTQCDk/dij+2DQ4
 6bmDCy/sBgcbz9mTpoLC11HLoPae6YN9nBNQRZDcEFEu54OaVOqlIdbA6m+POIBCXZdHOFc0
 WoDTgxHRzC1jgQNidyd6tKqcsVJs0dzF0oKTmFFmUAqTdJO12LBuNA1rlqrR3EtpYk8B/wtS
 5dIMD7Q8hwQpL+4C6GNpb6ZKnPkLi47pDOLhz2qBrqN+rqUEsT3YnExYpzj5yOBi+FlmV1Hw
 49QYe1sn2ZPs
In-Reply-To: <1571161.1742575348@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/30e7d162-408d-4d35-aa6a-1591d012b623%40dunslane.net>
Precedence: bulk

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


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

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

<!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 2025-03-21 Fr 12:42 PM, Tom Lane
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:1571161.1742575348@sss.pgh.pa.us">
      <pre wrap="" class="moz-quote-pre">Matheus Alcantara <a class="moz-txt-link-rfc2396E" href="mailto:matheusssilv97@gmail.com">&lt;matheusssilv97@gmail.com&gt;</a> writes:
</pre>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">On Thu, Mar 20, 2025 at 7:38 PM Andrew Dunstan <a class="moz-txt-link-rfc2396E" href="mailto:andrew@dunslane.net">&lt;andrew@dunslane.net&gt;</a> wrote:
</pre>
        <blockquote type="cite">
          <blockquote type="cite">
            <pre wrap="" class="moz-quote-pre">(wondering if this another of these cases where the "path includes postgres" thing bites us, and we're looking in the wrong place)
</pre>
          </blockquote>
        </blockquote>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
</pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <pre wrap="" class="moz-quote-pre">Nope, testing shows it's not that, so I am rather confused about what was going on.
</pre>
        </blockquote>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
</pre>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">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?
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
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 &gt;'/opt/postgres/build-farm-18/HEAD/pgsql.build'/tmp_install/log/install.log 2&gt;&amp;1
make -j1  checkprep &gt;&gt;'/opt/postgres/build-farm-18/HEAD/pgsql.build'/tmp_install/log/install.log 2&gt;&amp;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 &gt;&gt;'/opt/postgres/build-farm-18/HEAD/pgsql.build'/tmp_install/log/initdb-template.log 2&gt;&amp;1
echo "# +++ regress check in src/test/modules/test_extensions +++" &amp;&amp; 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 &gt;'$(abs_top_builddir)'/tmp_install/log/install.log 2&gt;&amp;1
	$(MAKE) -j1 $(if $(CHECKPREP_TOP),-C $(CHECKPREP_TOP),) checkprep &gt;&gt;'$(abs_top_builddir)'/tmp_install/log/install.log 2&gt;&amp;1</pre>
    </blockquote>
    <p><br>
    </p>
    <p>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.<br>
    </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>

--------------xBvjfl3RW4a8S5RbleFQecuj--