From: Michael Paquier <michael@paquier.xyz>
To: Matheus Alcantara <matheusssilv97@gmail.com>
Cc: Rahila Syed <rahilasyed90@gmail.com>
Cc: evsi@amazon.com
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1
Date: Tue, 3 Jun 2025 14:48:06 +0900
Message-ID: <aD6Mlr3Bow2yo_MH@paquier.xyz> (raw)
In-Reply-To: <CAFY6G8eVrLmOQ4gwONSbJFJ-8dygQpXY9qrAmzwD7t7ePjjRAA@mail.gmail.com>
References: <18920-b350b1c0a30af006@postgresql.org>
<CAFY6G8eGLJmdCCLP=MT9k=URegR6oG6Y1doOJXg65Efnzpz9cg@mail.gmail.com>
<CAH2L28uoo98D+u3dY319Ja4SWAV=mt19MkruWJjp7=N-Sqbn4g@mail.gmail.com>
<CAFY6G8eVrLmOQ4gwONSbJFJ-8dygQpXY9qrAmzwD7t7ePjjRAA@mail.gmail.com>
On Mon, Jun 02, 2025 at 07:56:01PM -0300, Matheus Alcantara wrote:
> On 02/06/25 16:56, Rahila Syed wrote:
>> Currently, the tests seem to be failing as follows for windows:
>>
>> [19:07:13.107] # Failed test 'create extension from custom extension
>> control path'[19:07:13.107] # at
>> C:/cirrus/src/test/modules/test_extensions/t/002_strip_modulepathname.pl
>> line 102.[19:07:13.107] # got: '2'[19:07:13.107] #
>> expected: '0'[19:07:13.107] # Looks like you failed 1 test of
>> 7.[19:07:13.107] [19:07:13.107] (test program exited with status code
>> 1)
>>
>> Details here: Windows - Server 2019, VS 2019 - Meson & ninja - Cirrus CI
>> <https://cirrus-ci.com/task/5241991606304768;
>
> Fixed, v2 attached. The 0001 patch remains the same as v1.
I am adding an open item for Peter Eisentraut, for 4f7f7b037585. The
patch looks sensible at quick glance, I did not check it in details
regarding the internals of dfmgr.c.
I don't like much the tests you are adding here. First, the
cross-platform requirements to copy a library to the plugins/ folder
is annoying. The actual issue is that we don't have an installation
rule to be able to install a library to a plugins/ path to allow
non-superusers to load it, no? I mean, as 4f7f7b037585 states, we
have a `make install prefix=/else/where` but the TAP tests cannot
shape a temporary installation with it. If we had something like that
for meson and makefiles, we could then reuse EXTRA_INSTALL to force a
library to exist where we want it to be, for the sake of testing
coverage.
I am not completely sure that the tests are completely waterproof,
either. Some distributions like fancy installation folder layers,
like Debian, and such things have proven to break these folk's tests.
Having a centralized rule could be also useful for out-of-core
extensions, to give these a way to install something inside a plugins/
folder. At least that may be better than requiring pg_config to get
the basic library install path.
Second, requiring dummy_index_am inside the tests test_extensions is
adding unwelcome complexity across the test modules.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (832B, ../aD6Mlr3Bow2yo_MH@paquier.xyz/2-signature.asc)
download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: michael@paquier.xyz, matheusssilv97@gmail.com, rahilasyed90@gmail.com, evsi@amazon.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1
In-Reply-To: <aD6Mlr3Bow2yo_MH@paquier.xyz>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox