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

From Matheus Alcantara
Subject Re: RFC: Additional Directory for Extensions
Date
Msg-id CAFY6G8eqwzdA=-L276izfq1jbPpjeDKRZW5oNs9j4DY5n7M=8Q@mail.gmail.com
Whole thread Raw
In response to Re: RFC: Additional Directory for Extensions  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: RFC: Additional Directory for Extensions
Re: RFC: Additional Directory for Extensions
List pgsql-hackers
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
--
Matheus Alcantara



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Parallel safety for extern params
Next
From: "David G. Johnston"
Date:
Subject: Re: Disabling vacuum truncate for autovacuum