Re: RFC: Additional Directory for Extensions

From: Matheus Alcantara <matheusssilv97(at)gmail(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Gabriele Bartolini <gabriele(dot)bartolini(at)enterprisedb(dot)com>, Craig Ringer <craig(dot)ringer(at)enterprisedb(dot)com>, "David E(dot) Wheeler" <david(at)justatheory(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: RFC: Additional Directory for Extensions
Date: 2025-03-21 15:52:55
Message-ID: CAFY6G8eqwzdA=-L276izfq1jbPpjeDKRZW5oNs9j4DY5n7M=8Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Mar 20, 2025 at 7:38 PM Andrew Dunstan <andrew(at)dunslane(dot)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, and the 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 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?

'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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David G. Johnston 2025-03-21 15:54:55 Re: Disabling vacuum truncate for autovacuum
Previous Message Tom Lane 2025-03-21 15:52:29 Re: Parallel safety for extern params