Re: RFC: Additional Directory for Extensions

On 19.03.25 20:25, Matheus Alcantara wrote:
> On Wed, Mar 19, 2025 at 3:56 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>
>> Peter Eisentraut <peter@eisentraut.org> writes:
>>> Committed that, thanks.
>>
>> 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"?
> 
> There is no specific reason to use "amcheck" instead of "plpgsql". Attached a
> patch with this change, sorry about that.

Committed.

I was able to reproduce the problem from scratch using:

./configure ...
make  # no contrib
make -C src/test/modules/test_extensions check

So it depended on in which order you build the various components.