pg.ddx.io pgsql-bugs@postgresql.org mailing list archive
help / color / mirror / Atom feedBUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1
12+ messages / 6 participants
[nested] [flat]
* BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1
@ 2025-05-08 19:55 PG Bug reporting form <noreply@postgresql.org>
2025-06-02 14:05 ` Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 Matheus Alcantara <matheusssilv97@gmail.com>
0 siblings, 1 reply; 12+ messages in thread
From: PG Bug reporting form @ 2025-05-08 19:55 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org; +Cc: evsi@amazon.com
The following bug has been logged on the website:
Bug reference: 18920
Logged by: Evan Si
Email address: evsi@amazon.com
PostgreSQL version: 18beta1
Operating system: Amazon Linux 2
Description:
Hi,
The 18beta1 documentation for the LOAD command has remained the same since
previous major versions.
https://www.postgresql.org/docs/18/sql-load.html
In the postgres installation, I can copy something e.g. auto_explain into a
plugins subdirectory of `pg_config --pkglibdir`
```
cp $(pg_config --pkglibdir)/auto_explain.so $(pg_config
--pkglibdir)/plugins/auto_explain.so
```
then from the server start:
```
psql (18beta1)
Type "help" for help.
postgres=# LOAD '$libdir/plugins/auto_explain.so';
ERROR: could not access file "plugins/auto_explain.so": No such file or
directory
postgres=# \q
```
This behavior differs from documentation and previous majors. It seems to me
that $libdir is getting stripped out from this commit:
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=4f7f7b0
--
Evan
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1
2025-05-08 19:55 BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 PG Bug reporting form <noreply@postgresql.org>
@ 2025-06-02 14:05 ` Matheus Alcantara <matheusssilv97@gmail.com>
2025-06-02 17:16 ` Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 Nathan Bossart <nathandbossart@gmail.com>
2025-06-02 19:56 ` Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 Rahila Syed <rahilasyed90@gmail.com>
0 siblings, 2 replies; 12+ messages in thread
From: Matheus Alcantara @ 2025-06-02 14:05 UTC (permalink / raw)
To: evsi@amazon.com; pgsql-bugs@lists.postgresql.org
Hi,
Thanks for reporting this!
On 08/05/25 16:55, PG Bug reporting form wrote:
> Hi,
> The 18beta1 documentation for the LOAD command has remained the same since
> previous major versions.
> https://www.postgresql.org/docs/18/sql-load.html
> In the postgres installation, I can copy something e.g. auto_explain into a
> plugins subdirectory of `pg_config --pkglibdir`
> ```
> cp $(pg_config --pkglibdir)/auto_explain.so $(pg_config
> --pkglibdir)/plugins/auto_explain.so
> ```
> then from the server start:
> ```
> psql (18beta1)
> Type "help" for help.
> postgres=# LOAD '$libdir/plugins/auto_explain.so';
> ERROR: could not access file "plugins/auto_explain.so": No such file or
> directory
> postgres=# \q
> ```
> This behavior differs from documentation and previous majors. It seems to me
> that $libdir is getting stripped out from this commit:
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=4f7f7b0
>
The problem is how we are sripping the $libdir from module_pathname. I
think that we should still strip the $libdir from module_pathname when
expanding from a .control file, but we should not expand via LOAD
command, since the user may explicitly specify the $libdir prefix as it
is the case here.
Having this logic on expand_dynamic_library_name() force us to srip the
$libdir for all scenarios, so I think that a better place to have this
is on load_external_function() that is called when executing a SQL
script from an extension. Another approach would be to change the
signature of expand_dynamic_library_name() to receive a boolean and only
srip the $libdir if it's true, but I think that the expand function
should not handle the strip logic, it should only expand the dynamic
library path and nothing else.
I'm also attaching a second patch that has a TAP test case that
reproduce this issue, it has some hacks to move dynamic library files
around to exercice the problem so I'm not sure if it could be good to
also include these tests on the final patch.
--
Matheus Alcantara
Attachments:
[application/octet-stream] v1-0001-Don-t-strip-libdir-from-LOAD-command.patch (2.1K, ../../CAFY6G8eGLJmdCCLP=MT9k=URegR6oG6Y1doOJXg65Efnzpz9cg@mail.gmail.com/2-v1-0001-Don-t-strip-libdir-from-LOAD-command.patch)
download | inline diff:
From 05af0217ae625200b580fe9582510a4db88a6ead Mon Sep 17 00:00:00 2001
From: Matheus Alcantara <mths.dev@pm.me>
Date: Mon, 2 Jun 2025 11:01:20 -0300
Subject: [PATCH v1 1/2] Don't strip $libdir from LOAD command
The 4f7f7b03758 commit implement the extension_control_path GUC, and to
make it work it was decided that we should strip the $libdir/ on
module_pathname from .control files, so that extensions don't need to
worry about this change.
This strip logic was implemented on expand_dynamic_library_name() which
works fine when executing the SQL functions from extensions but this
function is also called when the LOAD command is executed, and since the
user may explicitly pass the $libdir prefix on LOAD parameter we should
not strip in this case.
This commit fix this issue by moving the strip logic from
expand_dynamic_library_name() to load_external_function() that is called
when the running the SQL script from extensions.
---
src/backend/utils/fmgr/dfmgr.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/src/backend/utils/fmgr/dfmgr.c b/src/backend/utils/fmgr/dfmgr.c
index 603632581d0..4bb84ff7087 100644
--- a/src/backend/utils/fmgr/dfmgr.c
+++ b/src/backend/utils/fmgr/dfmgr.c
@@ -99,6 +99,14 @@ load_external_function(const char *filename, const char *funcname,
void *lib_handle;
void *retval;
+ /*
+ * If the value starts with "$libdir/", strip that. This is because many
+ * extensions have hardcoded '$libdir/foo' as their library name, which
+ * prevents using the path.
+ */
+ if (strncmp(filename, "$libdir/", 8) == 0)
+ filename += 8;
+
/* Expand the possibly-abbreviated filename to an exact path name */
fullname = expand_dynamic_library_name(filename);
@@ -456,14 +464,6 @@ expand_dynamic_library_name(const char *name)
Assert(name);
- /*
- * If the value starts with "$libdir/", strip that. This is because many
- * extensions have hardcoded '$libdir/foo' as their library name, which
- * prevents using the path.
- */
- if (strncmp(name, "$libdir/", 8) == 0)
- name += 8;
-
have_slash = (first_dir_separator(name) != NULL);
if (!have_slash)
--
2.39.5 (Apple Git-154)
[application/octet-stream] v1-0002-Add-TAP-tests-for-striping-libdir.patch (5.5K, ../../CAFY6G8eGLJmdCCLP=MT9k=URegR6oG6Y1doOJXg65Efnzpz9cg@mail.gmail.com/3-v1-0002-Add-TAP-tests-for-striping-libdir.patch)
download | inline diff:
From 67b0f2d8325b40d52fe62647a5dadf51f31bdebf Mon Sep 17 00:00:00 2001
From: Matheus Alcantara <mths.dev@pm.me>
Date: Mon, 2 Jun 2025 11:01:28 -0300
Subject: [PATCH v1 2/2] Add TAP tests for striping $libdir
---
src/test/modules/test_extensions/meson.build | 7 ++
.../t/002_strip_modulepathname.pl | 107 ++++++++++++++++++
2 files changed, 114 insertions(+)
create mode 100644 src/test/modules/test_extensions/t/002_strip_modulepathname.pl
diff --git a/src/test/modules/test_extensions/meson.build b/src/test/modules/test_extensions/meson.build
index 3c7e378bf35..1d8912e27a6 100644
--- a/src/test/modules/test_extensions/meson.build
+++ b/src/test/modules/test_extensions/meson.build
@@ -1,5 +1,9 @@
# Copyright (c) 2022-2025, PostgreSQL Global Development Group
+dummy_index_am_sources = files(
+ '../dummy_index_am/dummy_index_am.c',
+)
+
test_install_data += files(
'test_ext1--1.0.sql',
'test_ext1.control',
@@ -44,6 +48,8 @@ test_install_data += files(
'test_ext_req_schema3.control',
'test_ext_set_schema--1.0.sql',
'test_ext_set_schema.control',
+ '../dummy_index_am/dummy_index_am.control',
+ '../dummy_index_am/dummy_index_am--1.0.sql',
)
tests += {
@@ -60,6 +66,7 @@ tests += {
'tap': {
'tests': [
't/001_extension_control_path.pl',
+ 't/002_strip_modulepathname.pl',
],
},
}
diff --git a/src/test/modules/test_extensions/t/002_strip_modulepathname.pl b/src/test/modules/test_extensions/t/002_strip_modulepathname.pl
new file mode 100644
index 00000000000..fb36609ed05
--- /dev/null
+++ b/src/test/modules/test_extensions/t/002_strip_modulepathname.pl
@@ -0,0 +1,107 @@
+# Copyright (c) 2024-2025, PostgreSQL Global Development Group
+
+use strict;
+use warnings FATAL => 'all';
+use File::Path qw(mkpath);
+use PostgreSQL::Test::Cluster;
+use PostgreSQL::Test::Utils;
+use Test::More;
+use File::Copy;
+
+my $dlsuffix;
+
+if ($^O eq 'darwin') {
+ $dlsuffix = 'dylib';
+}
+elsif ($^O eq 'MSWin32') {
+ $dlsuffix = 'dll';
+}
+else {
+ $dlsuffix = 'so';
+}
+my $node = PostgreSQL::Test::Cluster->new('node');
+my $user = "user01";
+my $libdir = `pg_config --pkglibdir`;
+my $sharedir = `pg_config --sharedir`;
+chomp $libdir;
+chomp $sharedir;
+mkpath("$libdir/plugins");
+
+$node->init;
+
+# Create a temporary directory for the extension control file
+my $ext_dir = PostgreSQL::Test::Utils::tempdir();
+my $dyn_library_path = "$ext_dir/lib";
+mkpath("$ext_dir/extension");
+mkpath($dyn_library_path);
+
+# Use the correct separator and escape \ when running on Windows.
+my $sep = $windows_os ? ";" : ":";
+$node->append_conf(
+ 'postgresql.conf', qq{
+dynamic_library_path = '@{[ $windows_os ? ($dyn_library_path =~ s/\\/\\\\/gr) : $dyn_library_path ]}$sep\$libdir'
+extension_control_path = '@{[ $windows_os ? ($ext_dir =~ s/\\/\\\\/gr) : $ext_dir ]}$sep\$system'
+});
+
+$node->start;
+
+# Create a non-superuser user.
+$node->safe_psql('postgres', "CREATE USER $user");
+
+# --------------------------
+# Safe path. It should expand the dynamic library file from the $libdir as it
+# is specified on dummy_index_am.control and also on LOAD command.
+my $ret = $node->psql('postgres', "CREATE EXTENSION dummy_index_am");
+is($ret, 0, "create extension");
+$ret = $node->psql('postgres', "LOAD '\$libdir/dummy_index_am'");
+is($ret, 0, "LOAD dynamic module from \$libdir");
+
+$ret = $node->psql('postgres', "LOAD 'dummy_index_am'");
+is($ret, 0, "LOAD dynamic module");
+
+# --------------------------
+# Create an invalid dynamic library file so that we can ensure that we can
+# still load from $libdir if we want.
+open my $fh, '>', "$dyn_library_path/dummy_index_am.$dlsuffix" or die "Cannot create file: $!";
+close $fh;
+
+$ret = $node->psql('postgres', "LOAD '\$libdir/dummy_index_am'");
+is($ret, 0, "LOAD the correctly dynamic module from the \$libdir");
+
+# --------------------------
+# Copy the auto_explain from $libdir to $libdir/plugins so non-superusers can
+# LOAD
+copy("$libdir/auto_explain.$dlsuffix", "$libdir/plugins/auto_explain.$dlsuffix") or die "Copy failed: $!";
+
+$ret = $node->psql('postgres', "LOAD '\$libdir/plugins/auto_explain'",
+ connstr => $node->connstr('postgres') . qq' user=$user');
+is($ret, 0, "LOAD dynamic module from the \$libdir/plugins");
+
+# --------------------------
+# Move the dummy_index_am from $system and $libdir directory to a custom
+# directory to ensure that we can still load the dynamic library files that has
+# the $libdir/ prefix on module_pathname.
+$ret = $node->psql('postgres', "DROP EXTENSION dummy_index_am");
+is($ret, 0, "drop extension");
+
+$node->append_conf(
+ 'postgresql.conf', qq{
+dynamic_library_path = '@{[ $windows_os ? ($dyn_library_path =~ s/\\/\\\\/gr) : $dyn_library_path ]}'
+extension_control_path = '@{[ $windows_os ? ($ext_dir =~ s/\\/\\\\/gr) : $ext_dir ]}'
+});
+
+$node->stop;
+$node->start;
+
+copy("$sharedir/extension/dummy_index_am.control", "$ext_dir/extension/dummy_index_am.control") or die "Copy failed: $!";
+copy("$sharedir/extension/dummy_index_am--1.0.sql", "$ext_dir/extension/dummy_index_am--1.0.sql") or die "Copy failed: $!";
+copy("$libdir/dummy_index_am.$dlsuffix", "$dyn_library_path/dummy_index_am.$dlsuffix") or die "Copy failed: $!";
+unlink("$libdir/dummy_index_am.$dlsuffix");
+
+$ret = $node->psql('postgres', "CREATE EXTENSION dummy_index_am");
+is($ret, 0, "create extension from custom extension control path");
+
+# Copy again to $libdir to make it accessible to other tests
+copy("$dyn_library_path/dummy_index_am.$dlsuffix", "$libdir/dummy_index_am.$dlsuffix",) or die "Copy failed: $!";
+
+done_testing();
--
2.39.5 (Apple Git-154)
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1
2025-05-08 19:55 BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 PG Bug reporting form <noreply@postgresql.org>
2025-06-02 14:05 ` Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 Matheus Alcantara <matheusssilv97@gmail.com>
@ 2025-06-02 17:16 ` Nathan Bossart <nathandbossart@gmail.com>
1 sibling, 0 replies; 12+ messages in thread
From: Nathan Bossart @ 2025-06-02 17:16 UTC (permalink / raw)
To: Matheus Alcantara <matheusssilv97@gmail.com>; +Cc: evsi@amazon.com; pgsql-bugs@lists.postgresql.org; peter@eisentraut.org
On Mon, Jun 02, 2025 at 11:05:12AM -0300, Matheus Alcantara wrote:
> The problem is how we are sripping the $libdir from module_pathname. I
> think that we should still strip the $libdir from module_pathname when
> expanding from a .control file, but we should not expand via LOAD
> command, since the user may explicitly specify the $libdir prefix as it
> is the case here.
>
> Having this logic on expand_dynamic_library_name() force us to srip the
> $libdir for all scenarios, so I think that a better place to have this
> is on load_external_function() that is called when executing a SQL
> script from an extension.
Thanks for the patch. This seems generally reasonable to me.
--
nathan
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1
2025-05-08 19:55 BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 PG Bug reporting form <noreply@postgresql.org>
2025-06-02 14:05 ` Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 Matheus Alcantara <matheusssilv97@gmail.com>
@ 2025-06-02 19:56 ` Rahila Syed <rahilasyed90@gmail.com>
2025-06-02 20:53 ` Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 Matheus Alcantara <matheusssilv97@gmail.com>
2025-06-02 22:56 ` Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 Matheus Alcantara <matheusssilv97@gmail.com>
1 sibling, 2 replies; 12+ messages in thread
From: Rahila Syed @ 2025-06-02 19:56 UTC (permalink / raw)
To: Matheus Alcantara <matheusssilv97@gmail.com>; +Cc: evsi@amazon.com; pgsql-bugs@lists.postgresql.org
Hi,
Thank you both for the patch and the explanation regarding the fix.
> Another approach would be to change the
> signature of expand_dynamic_library_name() to receive a boolean and only
> srip the $libdir if it's true, but I think that the expand function
> should not handle the strip logic, it should only expand the dynamic
> library path and nothing else.
>
The reasoning makes sense to me.
> I'm also attaching a second patch that has a TAP test case that
> reproduce this issue, it has some hacks to move dynamic library files
> around to exercice the problem so I'm not sure if it could be good to
> also include these tests on the final patch.
>
The TAP test is useful in testing various paths of extension files.
It will be cleaner if the dummy_index_am.so is deleted at the end of the
tests from the $libdir.
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;
Thank you,
Rahila Syed
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1
2025-05-08 19:55 BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 PG Bug reporting form <noreply@postgresql.org>
2025-06-02 14:05 ` Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 Matheus Alcantara <matheusssilv97@gmail.com>
2025-06-02 19:56 ` Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 Rahila Syed <rahilasyed90@gmail.com>
@ 2025-06-02 20:53 ` Matheus Alcantara <matheusssilv97@gmail.com>
1 sibling, 0 replies; 12+ messages in thread
From: Matheus Alcantara @ 2025-06-02 20:53 UTC (permalink / raw)
To: Rahila Syed <rahilasyed90@gmail.com>; +Cc: evsi@amazon.com; pgsql-bugs@lists.postgresql.org
On 02/06/25 16:56, Rahila Syed wrote:
>> I'm also attaching a second patch that has a TAP test case that
>> reproduce this issue, it has some hacks to move dynamic library files
>> around to exercice the problem so I'm not sure if it could be good to
>> also include these tests on the final patch.
>>
>
> The TAP test is useful in testing various paths of extension files.
> It will be cleaner if the dummy_index_am.so is deleted at the end of the
> tests from the $libdir.
>
I think that the problem is that some other tests may use this
extension, so deleting at the end may cause other tests that use it to
fail depending on the other that is executed? I actually delete the .so
in the middle of the test but I copy it back to $libdir at the end to
avoid this possible side effect.
> 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;
>
Thanks, I'll take a look
--
Matheus Alcantara
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1
2025-05-08 19:55 BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 PG Bug reporting form <noreply@postgresql.org>
2025-06-02 14:05 ` Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 Matheus Alcantara <matheusssilv97@gmail.com>
2025-06-02 19:56 ` Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 Rahila Syed <rahilasyed90@gmail.com>
@ 2025-06-02 22:56 ` Matheus Alcantara <matheusssilv97@gmail.com>
2025-06-03 05:48 ` Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 Michael Paquier <michael@paquier.xyz>
1 sibling, 1 reply; 12+ messages in thread
From: Matheus Alcantara @ 2025-06-02 22:56 UTC (permalink / raw)
To: Rahila Syed <rahilasyed90@gmail.com>; +Cc: evsi@amazon.com; pgsql-bugs@lists.postgresql.org
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.
--
Matheus Alcantara
Attachments:
[application/octet-stream] v2-0001-Don-t-strip-libdir-from-LOAD-command.patch (2.1K, ../../CAFY6G8eVrLmOQ4gwONSbJFJ-8dygQpXY9qrAmzwD7t7ePjjRAA@mail.gmail.com/2-v2-0001-Don-t-strip-libdir-from-LOAD-command.patch)
download | inline diff:
From 05af0217ae625200b580fe9582510a4db88a6ead Mon Sep 17 00:00:00 2001
From: Matheus Alcantara <mths.dev@pm.me>
Date: Mon, 2 Jun 2025 11:01:20 -0300
Subject: [PATCH v2 1/2] Don't strip $libdir from LOAD command
The 4f7f7b03758 commit implement the extension_control_path GUC, and to
make it work it was decided that we should strip the $libdir/ on
module_pathname from .control files, so that extensions don't need to
worry about this change.
This strip logic was implemented on expand_dynamic_library_name() which
works fine when executing the SQL functions from extensions but this
function is also called when the LOAD command is executed, and since the
user may explicitly pass the $libdir prefix on LOAD parameter we should
not strip in this case.
This commit fix this issue by moving the strip logic from
expand_dynamic_library_name() to load_external_function() that is called
when the running the SQL script from extensions.
---
src/backend/utils/fmgr/dfmgr.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/src/backend/utils/fmgr/dfmgr.c b/src/backend/utils/fmgr/dfmgr.c
index 603632581d0..4bb84ff7087 100644
--- a/src/backend/utils/fmgr/dfmgr.c
+++ b/src/backend/utils/fmgr/dfmgr.c
@@ -99,6 +99,14 @@ load_external_function(const char *filename, const char *funcname,
void *lib_handle;
void *retval;
+ /*
+ * If the value starts with "$libdir/", strip that. This is because many
+ * extensions have hardcoded '$libdir/foo' as their library name, which
+ * prevents using the path.
+ */
+ if (strncmp(filename, "$libdir/", 8) == 0)
+ filename += 8;
+
/* Expand the possibly-abbreviated filename to an exact path name */
fullname = expand_dynamic_library_name(filename);
@@ -456,14 +464,6 @@ expand_dynamic_library_name(const char *name)
Assert(name);
- /*
- * If the value starts with "$libdir/", strip that. This is because many
- * extensions have hardcoded '$libdir/foo' as their library name, which
- * prevents using the path.
- */
- if (strncmp(name, "$libdir/", 8) == 0)
- name += 8;
-
have_slash = (first_dir_separator(name) != NULL);
if (!have_slash)
--
2.39.5 (Apple Git-154)
[application/octet-stream] v2-0002-Add-TAP-tests-for-striping-libdir.patch (5.3K, ../../CAFY6G8eVrLmOQ4gwONSbJFJ-8dygQpXY9qrAmzwD7t7ePjjRAA@mail.gmail.com/3-v2-0002-Add-TAP-tests-for-striping-libdir.patch)
download | inline diff:
From ca99aedbedf732cd8cb3eac60ddc3d16dd55e5ac Mon Sep 17 00:00:00 2001
From: Matheus Alcantara <mths.dev@pm.me>
Date: Mon, 2 Jun 2025 11:01:28 -0300
Subject: [PATCH v2 2/2] Add TAP tests for striping $libdir
---
src/test/modules/test_extensions/meson.build | 7 ++
.../t/002_strip_modulepathname.pl | 98 +++++++++++++++++++
2 files changed, 105 insertions(+)
create mode 100644 src/test/modules/test_extensions/t/002_strip_modulepathname.pl
diff --git a/src/test/modules/test_extensions/meson.build b/src/test/modules/test_extensions/meson.build
index 3c7e378bf35..1d8912e27a6 100644
--- a/src/test/modules/test_extensions/meson.build
+++ b/src/test/modules/test_extensions/meson.build
@@ -1,5 +1,9 @@
# Copyright (c) 2022-2025, PostgreSQL Global Development Group
+dummy_index_am_sources = files(
+ '../dummy_index_am/dummy_index_am.c',
+)
+
test_install_data += files(
'test_ext1--1.0.sql',
'test_ext1.control',
@@ -44,6 +48,8 @@ test_install_data += files(
'test_ext_req_schema3.control',
'test_ext_set_schema--1.0.sql',
'test_ext_set_schema.control',
+ '../dummy_index_am/dummy_index_am.control',
+ '../dummy_index_am/dummy_index_am--1.0.sql',
)
tests += {
@@ -60,6 +66,7 @@ tests += {
'tap': {
'tests': [
't/001_extension_control_path.pl',
+ 't/002_strip_modulepathname.pl',
],
},
}
diff --git a/src/test/modules/test_extensions/t/002_strip_modulepathname.pl b/src/test/modules/test_extensions/t/002_strip_modulepathname.pl
new file mode 100644
index 00000000000..2c40ab55382
--- /dev/null
+++ b/src/test/modules/test_extensions/t/002_strip_modulepathname.pl
@@ -0,0 +1,98 @@
+# Copyright (c) 2024-2025, PostgreSQL Global Development Group
+
+use strict;
+use warnings FATAL => 'all';
+use File::Path qw(mkpath);
+use PostgreSQL::Test::Cluster;
+use PostgreSQL::Test::Utils;
+use Test::More;
+use File::Copy;
+
+my $dlsuffix;
+
+if ($^O eq 'darwin') {
+ $dlsuffix = 'dylib';
+}
+elsif ($^O eq 'MSWin32') {
+ $dlsuffix = 'dll';
+}
+else {
+ $dlsuffix = 'so';
+}
+my $node = PostgreSQL::Test::Cluster->new('node');
+my $user = "user01";
+my $libdir = `pg_config --pkglibdir`;
+my $sharedir = `pg_config --sharedir`;
+chomp $libdir;
+chomp $sharedir;
+mkpath("$libdir/plugins");
+
+$node->init;
+
+# Create a temporary directory for the extension control file
+my $ext_dir = PostgreSQL::Test::Utils::tempdir();
+my $dyn_library_path = "$ext_dir/lib";
+mkpath("$ext_dir/extension");
+mkpath($dyn_library_path);
+
+# Use the correct separator and escape \ when running on Windows.
+my $sep = $windows_os ? ";" : ":";
+$node->append_conf(
+ 'postgresql.conf', qq{
+dynamic_library_path = '@{[ $windows_os ? ($dyn_library_path =~ s/\\/\\\\/gr) : $dyn_library_path ]}$sep\$libdir'
+extension_control_path = '@{[ $windows_os ? ($ext_dir =~ s/\\/\\\\/gr) : $ext_dir ]}$sep\$system'
+});
+
+$node->start;
+
+# Create a non-superuser user.
+$node->safe_psql('postgres', "CREATE USER $user");
+
+# --------------------------
+# Safe path. It should expand the dynamic library file from the $libdir as it
+# is specified on dummy_index_am.control and also on LOAD command.
+my $ret = $node->psql('postgres', "CREATE EXTENSION dummy_index_am");
+is($ret, 0, "create extension");
+$ret = $node->psql('postgres', "LOAD '\$libdir/dummy_index_am'");
+is($ret, 0, "LOAD dynamic module from \$libdir");
+
+$ret = $node->psql('postgres', "LOAD 'dummy_index_am'");
+is($ret, 0, "LOAD dynamic module");
+
+# --------------------------
+# Create an invalid dynamic library file so that we can ensure that we can
+# still load from $libdir if we want.
+open my $fh, '>', "$dyn_library_path/dummy_index_am.$dlsuffix" or die "Cannot create file: $!";
+close $fh;
+
+$ret = $node->psql('postgres', "LOAD '\$libdir/dummy_index_am'");
+is($ret, 0, "LOAD the correctly dynamic module from the \$libdir");
+
+# --------------------------
+# Copy the auto_explain from $libdir to $libdir/plugins so non-superusers can
+# LOAD
+copy("$libdir/auto_explain.$dlsuffix", "$libdir/plugins/auto_explain.$dlsuffix") or die "Copy failed: $!";
+
+$ret = $node->psql('postgres', "LOAD '\$libdir/plugins/auto_explain'",
+ connstr => $node->connstr('postgres') . qq' user=$user');
+is($ret, 0, "LOAD dynamic module from the \$libdir/plugins");
+
+# --------------------------
+# Move the dummy_index_am from $system and $libdir directory to a custom
+# directory to ensure that we can still load the dynamic library files that has
+# the $libdir/ prefix on module_pathname.
+$ret = $node->psql('postgres', "DROP EXTENSION dummy_index_am");
+is($ret, 0, "drop extension");
+
+copy("$sharedir/extension/dummy_index_am.control", "$ext_dir/extension/dummy_index_am.control") or die "Copy failed: $!";
+copy("$sharedir/extension/dummy_index_am--1.0.sql", "$ext_dir/extension/dummy_index_am--1.0.sql") or die "Copy failed: $!";
+copy("$libdir/dummy_index_am.$dlsuffix", "$dyn_library_path/dummy_index_am.$dlsuffix") or die "Copy failed: $!";
+unlink("$libdir/dummy_index_am.$dlsuffix");
+
+$ret = $node->psql('postgres', "CREATE EXTENSION dummy_index_am");
+is($ret, 0, "create extension from custom extension control path");
+
+# Copy again to $libdir to make it accessible to other tests
+copy("$dyn_library_path/dummy_index_am.$dlsuffix", "$libdir/dummy_index_am.$dlsuffix",) or die "Copy failed: $!";
+
+done_testing();
--
2.39.5 (Apple Git-154)
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1
2025-05-08 19:55 BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 PG Bug reporting form <noreply@postgresql.org>
2025-06-02 14:05 ` Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 Matheus Alcantara <matheusssilv97@gmail.com>
2025-06-02 19:56 ` Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 Rahila Syed <rahilasyed90@gmail.com>
2025-06-02 22:56 ` Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 Matheus Alcantara <matheusssilv97@gmail.com>
@ 2025-06-03 05:48 ` Michael Paquier <michael@paquier.xyz>
2025-06-03 12:31 ` Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 Matheus Alcantara <matheusssilv97@gmail.com>
0 siblings, 1 reply; 12+ messages in thread
From: Michael Paquier @ 2025-06-03 05:48 UTC (permalink / raw)
To: Matheus Alcantara <matheusssilv97@gmail.com>; +Cc: Rahila Syed <rahilasyed90@gmail.com>; evsi@amazon.com; pgsql-bugs@lists.postgresql.org
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
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1
2025-05-08 19:55 BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 PG Bug reporting form <noreply@postgresql.org>
2025-06-02 14:05 ` Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 Matheus Alcantara <matheusssilv97@gmail.com>
2025-06-02 19:56 ` Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 Rahila Syed <rahilasyed90@gmail.com>
2025-06-02 22:56 ` Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 Matheus Alcantara <matheusssilv97@gmail.com>
2025-06-03 05:48 ` Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 Michael Paquier <michael@paquier.xyz>
@ 2025-06-03 12:31 ` Matheus Alcantara <matheusssilv97@gmail.com>
2025-06-04 00:44 ` Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 Michael Paquier <michael@paquier.xyz>
0 siblings, 1 reply; 12+ messages in thread
From: Matheus Alcantara @ 2025-06-03 12:31 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; +Cc: Rahila Syed <rahilasyed90@gmail.com>; evsi@amazon.com; pgsql-bugs@lists.postgresql.org
On 03/06/25 02:48, Michael Paquier wrote:
> 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.
>
I also don't like these tests, it has a lot of hacks as I've mentioned in
my first email and I'm almost sure that if we push this it will not work
on a lot of build farm animals. I just wrote these tests to make it
possible to reproduce the issue on my local machine and make the fix
easier, and I just shared here so that folks can also have a way to
reproduce the issue and maybe share other ideas to test this.
--
Matheus Alcantara
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1
2025-05-08 19:55 BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 PG Bug reporting form <noreply@postgresql.org>
2025-06-02 14:05 ` Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 Matheus Alcantara <matheusssilv97@gmail.com>
2025-06-02 19:56 ` Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 Rahila Syed <rahilasyed90@gmail.com>
2025-06-02 22:56 ` Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 Matheus Alcantara <matheusssilv97@gmail.com>
2025-06-03 05:48 ` Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 Michael Paquier <michael@paquier.xyz>
2025-06-03 12:31 ` Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 Matheus Alcantara <matheusssilv97@gmail.com>
@ 2025-06-04 00:44 ` Michael Paquier <michael@paquier.xyz>
2025-06-04 09:42 ` Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 Peter Eisentraut <peter@eisentraut.org>
2025-06-04 11:31 ` Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 Matheus Alcantara <matheusssilv97@gmail.com>
0 siblings, 2 replies; 12+ messages in thread
From: Michael Paquier @ 2025-06-04 00:44 UTC (permalink / raw)
To: Matheus Alcantara <matheusssilv97@gmail.com>; +Cc: Rahila Syed <rahilasyed90@gmail.com>; evsi@amazon.com; pgsql-bugs@lists.postgresql.org
On Tue, Jun 03, 2025 at 09:31:17AM -0300, Matheus Alcantara wrote:
> I just wrote these tests to make it
> possible to reproduce the issue on my local machine and make the fix
> easier, and I just shared here so that folks can also have a way to
> reproduce the issue and maybe share other ideas to test this.
+1. These are useful to check the patch, there's no denying that. My
apologies if my previous message was confusing.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (832B, ../../aD-W0yQH7UjkQkXc@paquier.xyz/2-signature.asc)
download
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1
2025-05-08 19:55 BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 PG Bug reporting form <noreply@postgresql.org>
2025-06-02 14:05 ` Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 Matheus Alcantara <matheusssilv97@gmail.com>
2025-06-02 19:56 ` Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 Rahila Syed <rahilasyed90@gmail.com>
2025-06-02 22:56 ` Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 Matheus Alcantara <matheusssilv97@gmail.com>
2025-06-03 05:48 ` Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 Michael Paquier <michael@paquier.xyz>
2025-06-03 12:31 ` Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 Matheus Alcantara <matheusssilv97@gmail.com>
2025-06-04 00:44 ` Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 Michael Paquier <michael@paquier.xyz>
@ 2025-06-04 09:42 ` Peter Eisentraut <peter@eisentraut.org>
2025-06-04 11:32 ` Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 Matheus Alcantara <matheusssilv97@gmail.com>
1 sibling, 1 reply; 12+ messages in thread
From: Peter Eisentraut @ 2025-06-04 09:42 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; Matheus Alcantara <matheusssilv97@gmail.com>; +Cc: Rahila Syed <rahilasyed90@gmail.com>; evsi@amazon.com; pgsql-bugs@lists.postgresql.org
On 04.06.25 02:44, Michael Paquier wrote:
> On Tue, Jun 03, 2025 at 09:31:17AM -0300, Matheus Alcantara wrote:
>> I just wrote these tests to make it
>> possible to reproduce the issue on my local machine and make the fix
>> easier, and I just shared here so that folks can also have a way to
>> reproduce the issue and maybe share other ideas to test this.
>
> +1. These are useful to check the patch, there's no denying that. My
> apologies if my previous message was confusing.
I have committed the patch without the additional tests, as discussed.
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1
2025-05-08 19:55 BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 PG Bug reporting form <noreply@postgresql.org>
2025-06-02 14:05 ` Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 Matheus Alcantara <matheusssilv97@gmail.com>
2025-06-02 19:56 ` Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 Rahila Syed <rahilasyed90@gmail.com>
2025-06-02 22:56 ` Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 Matheus Alcantara <matheusssilv97@gmail.com>
2025-06-03 05:48 ` Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 Michael Paquier <michael@paquier.xyz>
2025-06-03 12:31 ` Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 Matheus Alcantara <matheusssilv97@gmail.com>
2025-06-04 00:44 ` Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 Michael Paquier <michael@paquier.xyz>
2025-06-04 09:42 ` Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 Peter Eisentraut <peter@eisentraut.org>
@ 2025-06-04 11:32 ` Matheus Alcantara <matheusssilv97@gmail.com>
0 siblings, 0 replies; 12+ messages in thread
From: Matheus Alcantara @ 2025-06-04 11:32 UTC (permalink / raw)
To: Peter Eisentraut <peter@eisentraut.org>; +Cc: Michael Paquier <michael@paquier.xyz>; Rahila Syed <rahilasyed90@gmail.com>; evsi@amazon.com; pgsql-bugs@lists.postgresql.org
On Wed, Jun 4, 2025 at 6:42 AM Peter Eisentraut <peter@eisentraut.org> wrote:
>
> On 04.06.25 02:44, Michael Paquier wrote:
> > On Tue, Jun 03, 2025 at 09:31:17AM -0300, Matheus Alcantara wrote:
> >> I just wrote these tests to make it
> >> possible to reproduce the issue on my local machine and make the fix
> >> easier, and I just shared here so that folks can also have a way to
> >> reproduce the issue and maybe share other ideas to test this.
> >
> > +1. These are useful to check the patch, there's no denying that. My
> > apologies if my previous message was confusing.
>
> I have committed the patch without the additional tests, as discussed.
>
Thanks!
--
Matheus Alcantara
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1
2025-05-08 19:55 BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 PG Bug reporting form <noreply@postgresql.org>
2025-06-02 14:05 ` Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 Matheus Alcantara <matheusssilv97@gmail.com>
2025-06-02 19:56 ` Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 Rahila Syed <rahilasyed90@gmail.com>
2025-06-02 22:56 ` Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 Matheus Alcantara <matheusssilv97@gmail.com>
2025-06-03 05:48 ` Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 Michael Paquier <michael@paquier.xyz>
2025-06-03 12:31 ` Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 Matheus Alcantara <matheusssilv97@gmail.com>
2025-06-04 00:44 ` Re: BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 Michael Paquier <michael@paquier.xyz>
@ 2025-06-04 11:31 ` Matheus Alcantara <matheusssilv97@gmail.com>
1 sibling, 0 replies; 12+ messages in thread
From: Matheus Alcantara @ 2025-06-04 11:31 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; +Cc: Rahila Syed <rahilasyed90@gmail.com>; evsi@amazon.com; pgsql-bugs@lists.postgresql.org
On Tue, Jun 3, 2025 at 9:44 PM Michael Paquier <michael@paquier.xyz> wrote:
>
> On Tue, Jun 03, 2025 at 09:31:17AM -0300, Matheus Alcantara wrote:
> > I just wrote these tests to make it
> > possible to reproduce the issue on my local machine and make the fix
> > easier, and I just shared here so that folks can also have a way to
> > reproduce the issue and maybe share other ideas to test this.
>
> +1. These are useful to check the patch, there's no denying that. My
> apologies if my previous message was confusing.
>
No worries, thanks very much for the comments and taking time to review!
--
Matheus Alcantara
^ permalink raw reply [nested|flat] 12+ messages in thread
end of thread, other threads:[~2025-06-04 11:32 UTC | newest]
Thread overview: 12+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2025-05-08 19:55 BUG #18920: LOAD '$libdir/plugins' no longer works in 18beta1 PG Bug reporting form <noreply@postgresql.org>
2025-06-02 14:05 ` Matheus Alcantara <matheusssilv97@gmail.com>
2025-06-02 17:16 ` Nathan Bossart <nathandbossart@gmail.com>
2025-06-02 19:56 ` Rahila Syed <rahilasyed90@gmail.com>
2025-06-02 20:53 ` Matheus Alcantara <matheusssilv97@gmail.com>
2025-06-02 22:56 ` Matheus Alcantara <matheusssilv97@gmail.com>
2025-06-03 05:48 ` Michael Paquier <michael@paquier.xyz>
2025-06-03 12:31 ` Matheus Alcantara <matheusssilv97@gmail.com>
2025-06-04 00:44 ` Michael Paquier <michael@paquier.xyz>
2025-06-04 09:42 ` Peter Eisentraut <peter@eisentraut.org>
2025-06-04 11:32 ` Matheus Alcantara <matheusssilv97@gmail.com>
2025-06-04 11:31 ` Matheus Alcantara <matheusssilv97@gmail.com>
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