Re: RFC: Additional Directory for Extensions - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: RFC: Additional Directory for Extensions
Date
Msg-id 3d7cca86-adce-4a57-95f7-27d28af2cb27@dunslane.net
Whole thread Raw
In response to Re: RFC: Additional Directory for Extensions  (Matheus Alcantara <matheusssilv97@gmail.com>)
List pgsql-hackers
On 2025-03-21 Fr 11:52 AM, Matheus Alcantara wrote:
> On Thu, Mar 20, 2025 at 7:38 PM Andrew Dunstan <andrew@dunslane.net> wrote:
>>>> Buildfarm member snakefly doesn't like this too much.  Since no other
>>>> animals have failed, I guess it must be about local conditions on
>>>> that machine, but the report is pretty opaque:
>>>>
>>>> # +++ tap check in src/test/modules/test_extensions +++
>>>>
>>>> #   Failed test '$system extension is installed correctly on pg_available_extensions'
>>>> #   at t/001_extension_control_path.pl line 69.
>>>> #          got: 'f'
>>>> #     expected: 't'
>>>>
>>>> #   Failed test '$system extension is installed correctly on pg_available_extensions with empty
extension_control_path'
>>>> #   at t/001_extension_control_path.pl line 76.
>>>> #          got: 'f'
>>>> #     expected: 't'
>>>> # Looks like you failed 2 tests of 5.
>>>> [06:43:53] t/001_extension_control_path.pl ..
>>>> Dubious, test returned 2 (wstat 512, 0x200)
>>>> Failed 2/5 subtests
>>>>
>>>> Looking at the test, it presupposes that "amcheck" must be an
>>>> available extension.  I do not see anything that guarantees
>>>> that that's so, though.  It'd fail if contrib hasn't been
>>>> installed.  Is there a reason to use "amcheck" rather than
>>>> something more certainly available, like "plpgsql"?
>>> I think something else must be going on. The failure in question came after the step "install-contrib" succeeded,
andthe log file for that shows:
 
>>>
>>>
>>> make[1]: Entering directory `/opt/postgres/build-farm-18/HEAD/pgsql.build/contrib/amcheck'
>>> /usr/bin/mkdir -p
'/opt/postgres/build-farm-18/HEAD/pgsql.build/tmp_install/opt/postgres/build-farm-18/HEAD/inst/lib'
>>> /usr/bin/mkdir -p
'/opt/postgres/build-farm-18/HEAD/pgsql.build/tmp_install/opt/postgres/build-farm-18/HEAD/inst/share/extension'
>>> /usr/bin/mkdir -p
'/opt/postgres/build-farm-18/HEAD/pgsql.build/tmp_install/opt/postgres/build-farm-18/HEAD/inst/share/extension'
>>> /usr/bin/install -c -m 755  amcheck.so
'/opt/postgres/build-farm-18/HEAD/pgsql.build/tmp_install/opt/postgres/build-farm-18/HEAD/inst/lib/amcheck.so'
>>> /usr/bin/install -c -m 644 ./amcheck.control
'/opt/postgres/build-farm-18/HEAD/pgsql.build/tmp_install/opt/postgres/build-farm-18/HEAD/inst/share/extension/'
>>> /usr/bin/install -c -m 644 ./amcheck--1.3--1.4.sql ./amcheck--1.2--1.3.sql ./amcheck--1.1--1.2.sql
./amcheck--1.0--1.1.sql./amcheck--1.0.sql
'/opt/postgres/build-farm-18/HEAD/pgsql.build/tmp_install/opt/postgres/build-farm-18/HEAD/inst/share/extension/'
>>> make[1]: Leaving directory `/opt/postgres/build-farm-18/HEAD/pgsql.build/contrib/amcheck'
>>>
>>>
>>> (wondering if this another of these cases where the "path includes postgres" thing bites us, and we're looking in
thewrong 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?
>
> 'steps_completed' => [
>                        'SCM-checkout',
>                        'Configure',
>                        'Build',
>                        'Check',
>                        'Contrib',
>                        'TestModules',
>                        'Install',
>                        'ContribInstall',
>                        'TestModulesInstall',
>                        'MiscCheck',
>                        ...
>                        ]
>
> [1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=snakefly&dt=2025-03-20%2009%3A46%3A05


No. In the buildfarm, the Check step only runs the core regression 
tests, not any TAP tests. The above shows fairly clearly that the 
failure occurred after the ContribInstall step, which is what's puzzling me.


cheers


andrew

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




pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: sinvaladt.c: remove msgnumLock, use atomic operations on maxMsgNum
Next
From: Peter Eisentraut
Date:
Subject: Re: Next commitfest app release is planned for March 18th