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
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 |