Extension uninstall issue with PGXS
Hi all, I am in trouble when building an extension with PGXS. At uninstall time, the documentation and script files are not removed. The specificity of my distribution tree is that these script and documentation files are located into subdirectories. So in the Makefile, the DOCS and SCRIPTS variables are described like DATA, with something like: DOCS = \$(wildcard doc/*) SCRIPTS = \$(wildcard script/*) At install time, all files of both subdirectories are correctly copied into the DOCDIR and BINDIR directories respectively. But at uninstall time, these files are not removed. Attached is a simple test case that reproduces the issue, with the execution result on my PC. As you can see, the uninstall step tries to remove files from DOCDIR and BINDIR, using the original subdirectories. I don't know if this can be considered as a bug or if it is a functional limitation or if there is a better way to code the Makefile. Kind regards. Philippe. testcase.sh Description: application/shellscript Install the extension make: rien à faire pour « all ». /bin/mkdir -p '/usr/share/postgresql/14/extension' /bin/mkdir -p '/usr/share/postgresql/14/myext' /bin/mkdir -p '/usr/share/doc/postgresql-doc-14/myext' /bin/mkdir -p '/usr/lib/postgresql/14/bin' /usr/bin/install -c -m 644 .//myext.control '/usr/share/postgresql/14/extension/' /usr/bin/install -c -m 644 .//sql/myext_1.0.0.sql '/usr/share/postgresql/14/myext/' /usr/bin/install -c -m 644 .//doc/mydoc1 .//doc/mydoc2 '/usr/share/doc/postgresql-doc-14/myext/' /usr/bin/install -c -m 755 .//script/myscript1 .//script/myscript2 '/usr/lib/postgresql/14/bin/' Check /usr/share/postgresql/14/extension/myext.control myext_1.0.0.sql /usr/lib/postgresql/14/bin/myscript1 /usr/lib/postgresql/14/bin/myscript2 mydoc1 mydoc2 Uninstall the extension rm -f '/usr/share/postgresql/14/extension'/myext.control rm -f '/usr/share/postgresql/14/myext'/myext_1.0.0.sql rm -f '/usr/share/doc/postgresql-doc-14/myext'/doc/mydoc1 '/usr/share/doc/postgresql-doc-14/myext'/doc/mydoc2 rm -f '/usr/lib/postgresql/14/bin'/script/myscript1 '/usr/lib/postgresql/14/bin'/script/myscript2 Check (nothing should be found here) ls: impossible d'accéder à '/usr/share/postgresql/14/extension/myext.control': Aucun fichier ou dossier de ce nom ls: impossible d'accéder à '/usr/share/postgresql/14/extension/myext': Aucun fichier ou dossier de ce nom /usr/lib/postgresql/14/bin/myscript1 /usr/lib/postgresql/14/bin/myscript2 mydoc1 mydoc2
problem loading shared lib pg_tde.so
I have a problem while loading the pg_tde.so shared lib. contrib/pg_tde was built with: cd postgresql-16.2/contrib/pg_tde || exit gmake clean export LDFLAGS="-L/usr/local/sisis-pap/lib -L/usr/lib64" export CFLAGS="-m64 -I/usr/local/sisis-pap/include" export CPPFLAGS="-m64 -I/usr/local/sisis-pap/include" ./configure --prefix=/usr/local/sisis-pap/pgsql-16.2 \ --libdir=/usr/local/sisis-pap/pgsql-16.2/lib --with-libcurl=/usr/local/sisis-pap/ gmake gmake install but the shared lib /usr/local/sisis-pap/pgsql-16.2/lib/pg_tde.so can't be loaded on startup of the server: 024-05-06 11:18:45.967 CEST [15368] FATAL: could not load library "/usr/local/sisis-pap/pgsql-16.2/lib/pg_tde.so": /usr/lib64/libssh.so.4: undefined symbol: EVP_KDF_CTX_new_id, version OPENSSL_1_1_1d 2024-05-06 11:18:45.967 CEST [15368] LOG: database system is shut down This is the OpenSSL version of SuSE Linux Enterprise 15 SP5: # openssl version OpenSSL 1.1.1l-fips 24 Aug 2021 SUSE release 150500.17.25.1 This is what we have compiled and PostgreSQL should use: # export LD_LIBRARY_PATH=/usr/local/sisis-pap/lib # /usr/local/sisis-pap/bin/openssl version OpenSSL 1.1.1t 7 Feb 2023 When I disable 'pg_tde' in data/postgresql.auto.conf the server starts fine; vim /data/postgresql162/data/postgresql.auto.conf # disabled shared_preload_libraries = 'pg_tde' # /etc/init.d/postgres162 start starts fine and the postgres proc is using our libssl.so.1.1 # lsof -p 17254 | egrep 'libssl' postgres 17254 postgres mem REG 254,0 697248 1080241 /usr/local/sisis-pap/lib/libssl.so.1.1 # strings /usr/local/sisis-pap/lib/libssl.so.1.1 | grep EVP_KDF (nix) # strings /usr/lib64/libssh.so.4 | grep EVP_KDF EVP_KDF_CTX_new_id EVP_KDF_ctrl EVP_KDF_CTX_free EVP_KDF_derive I have a complete different OpenSSL 3.0.x environment: all OpenSSL consumers use /usr/local/sisis-pap.sp01/lib/libssl.so.3, also PostgreSQL and pg_tde have been compiled against this; and this runs fine with 'pg_tde'. What the avove error means? Thanks matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub
Clarification Needed on Postgresql License Requirement for Hybrid Environment Cluster Configuration
Hi, I hope this email finds you well. I am reaching out to seek clarification on a matter regarding the configuration of a cluster in a hybrid environment. Specifically, I am wondering whether we require a PostgreSQL license for setting up a cluster in such an environment. Could you kindly provide some guidance or clarification on this matter? Your expertise and insights on this issue would be greatly appreciated. Thank you in advance for your assistance. Looking forward to your prompt response. Best regards, Prasanna
Re: Clarification Needed on Postgresql License Requirement for Hybrid Environment Cluster Configuration
Hello, On 2024-May-06, Prasanna Chavan wrote: > I hope this email finds you well. I am reaching out to seek > clarification on a matter regarding the configuration of a cluster in > a hybrid environment. > Specifically, I am wondering whether we require a PostgreSQL license > for setting up a cluster in such an environment. Could you kindly > provide some guidance or clarification on this matter? Yes, you require a license. However, luckily for you, the license is provided for any purpose, without fee, and without a written agreement. The COPYRIGHT file in the source distribution contains the details. You can use the software standalone or in cluster configuration, as you see fit. In short, you don't need to worry about it. However, this doesn't necessarily apply to other software packages derived from PostgreSQL itself, or those that work in conjunction with it, such as Postgres extensions, admin interfaces, GUIs, monitoring packages, etc. You'll have to seek clarification on each such software package that you intend to use. -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ "I dream about dreams about dreams", sang the nightingale under the pale moon (Sandman)
Re: problem loading shared lib pg_tde.so
On 5/6/24 04:05, Matthias Apitz wrote: I have a problem while loading the pg_tde.so shared lib. contrib/pg_tde was built with: cd postgresql-16.2/contrib/pg_tde || exit gmake clean export LDFLAGS="-L/usr/local/sisis-pap/lib -L/usr/lib64" export CFLAGS="-m64 -I/usr/local/sisis-pap/include" export CPPFLAGS="-m64 -I/usr/local/sisis-pap/include" ./configure --prefix=/usr/local/sisis-pap/pgsql-16.2 \ --libdir=/usr/local/sisis-pap/pgsql-16.2/lib --with-libcurl=/usr/local/sisis-pap/ gmake gmake install but the shared lib /usr/local/sisis-pap/pgsql-16.2/lib/pg_tde.so can't be loaded on startup of the server: 024-05-06 11:18:45.967 CEST [15368] FATAL: could not load library "/usr/local/sisis-pap/pgsql-16.2/lib/pg_tde.so": /usr/lib64/libssh.so.4: undefined symbol: EVP_KDF_CTX_new_id, version OPENSSL_1_1_1d 2024-05-06 11:18:45.967 CEST [15368] LOG: database system is shut down This is the OpenSSL version of SuSE Linux Enterprise 15 SP5: # openssl version OpenSSL 1.1.1l-fips 24 Aug 2021 SUSE release 150500.17.25.1 This is what we have compiled and PostgreSQL should use: # export LD_LIBRARY_PATH=/usr/local/sisis-pap/lib # /usr/local/sisis-pap/bin/openssl version OpenSSL 1.1.1t 7 Feb 2023 I see three different versions of OpenSSL: OPENSSL_1_1_1d -- From error messsage OpenSSL 1.1.1l-fips -- SuSE 15 version OpenSSL 1.1.1t -- Your built version? Are you sure you pointing at the same version in all cases? When I disable 'pg_tde' in data/postgresql.auto.conf the server starts fine; vim /data/postgresql162/data/postgresql.auto.conf # disabled shared_preload_libraries = 'pg_tde' # /etc/init.d/postgres162 start starts fine and the postgres proc is using our libssl.so.1.1 # lsof -p 17254 | egrep 'libssl' postgres 17254 postgres mem REG 254,0 697248 1080241 /usr/local/sisis-pap/lib/libssl.so.1.1 # strings /usr/local/sisis-pap/lib/libssl.so.1.1 | grep EVP_KDF (nix) # strings /usr/lib64/libssh.so.4 | grep EVP_KDF EVP_KDF_CTX_new_id EVP_KDF_ctrl EVP_KDF_CTX_free EVP_KDF_derive I have a complete different OpenSSL 3.0.x environment: all OpenSSL consumers use /usr/local/sisis-pap.sp01/lib/libssl.so.3, also PostgreSQL and pg_tde have been compiled against this; and this runs fine with 'pg_tde'. What the avove error means? Thanks matthias -- Adrian Klaver adrian.kla...@aklaver.com
Re: problem loading shared lib pg_tde.so
On 5/6/24 07:42, Adrian Klaver wrote: On 5/6/24 04:05, Matthias Apitz wrote: I see three different versions of OpenSSL: OPENSSL_1_1_1d -- From error messsage OpenSSL 1.1.1l-fips -- SuSE 15 version OpenSSL 1.1.1t -- Your built version? Are you sure you pointing at the same version in all cases? Should have added what does the below return?: ldd /usr/local/sisis-pap/pgsql-16.2/lib/pg_tde.so matthias -- Adrian Klaver adrian.kla...@aklaver.com
Re: problem loading shared lib pg_tde.so
El día lunes, mayo 06, 2024 a las 07:45:52 -0700, Adrian Klaver escribió: > On 5/6/24 07:42, Adrian Klaver wrote: > > On 5/6/24 04:05, Matthias Apitz wrote: > > > > > I see three different versions of OpenSSL: > > > > OPENSSL_1_1_1d -- From error messsage > > OpenSSL 1.1.1l-fips -- SuSE 15 version > > OpenSSL 1.1.1t -- Your built version? > > > > Are you sure you pointing at the same version in all cases? Yes, to my built version. > > Should have added what does the below return?: > > ldd /usr/local/sisis-pap/pgsql-16.2/lib/pg_tde.so I added in the start script of the server the following line about ldd, to get it exactly in the LD_LIBRARY_PATH of the server: ... case $1 in start) echo -n "Starting PostgreSQL: " test -e "$PG_OOM_ADJUST_FILE" && echo "$PG_MASTER_OOM_SCORE_ADJ" > "$PG_OOM_ADJUST_FILE" su - $PGUSER -c "$LD_ENV $DAEMON_ENV env > /tmp/pg_tde.ldd" su - $PGUSER -c "$LD_ENV $DAEMON_ENV ldd /usr/local/sisis-pap/pgsql-16.2/lib/pg_tde.so >> /tmp/pg_tde.ldd" su - $PGUSER -c "$LD_ENV $DAEMON_ENV $DAEMON -D '$PGDATA' >>$PGLOG 2>&1 &" echo "ok" ;; ... After looking carefully at the file /tmp/pg_tde.ldd I saw the problem: # egrep 'LD_LIBRARY_PATH|libcurl' /tmp/pg_tde.ldd LD_LIBRARY_PATH=:/usr/local/sisis-pap/lib libcurl.so.4 => /usr/lib64/libcurl.so.4 (0x7fc830146000) LD_LIBRARY_PATH was set as it should to /usr/local/sisis-pap/lib but the libcurl.so.4 was not seen. I made curl by my own and this installed: # ls -l /usr/local/sisis-pap/lib/libcurl* -rw-r--r-- 1 bin bin 1315526 May 6 10:29 /usr/local/sisis-pap/lib/libcurl.a -rwxr-xr-x 1 bin bin1004 May 6 10:29 /usr/local/sisis-pap/lib/libcurl.la -rwxr-xr-x 1 bin bin 735168 May 6 10:29 /usr/local/sisis-pap/lib/libcurl.so.4.8.0 but the pg_tde.so was loocking for libcurl.so.4 and not for libcurl.so.4.8.0 I made a symlink as # ln -s /usr/local/sisis-pap/lib/libcurl.so.4.8.0 /usr/local/sisis-pap/lib/libcurl.so.4 and the server comes up fine: # /etc/init.d/postgres162 start Starting PostgreSQL: ok # grep curl /tmp/pg_tde.ldd libcurl.so.4 => /usr/local/sisis-pap/lib/libcurl.so.4 (0x7faefc8bd000) I have to figure out why the making of 'curl' does not produce that symlink by its own, or why the making of pg_tde.so let it ask for libcurl.so.4 and not for libcurl.so.4.8.0. Thanks for your help, Adrian. matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub
Re: problem loading shared lib pg_tde.so
El día martes, mayo 07, 2024 a las 07:07:22 +0200, Matthias Apitz escribió: > # ls -l /usr/local/sisis-pap/lib/libcurl* > -rw-r--r-- 1 bin bin 1315526 May 6 10:29 /usr/local/sisis-pap/lib/libcurl.a > -rwxr-xr-x 1 bin bin1004 May 6 10:29 /usr/local/sisis-pap/lib/libcurl.la > -rwxr-xr-x 1 bin bin 735168 May 6 10:29 > /usr/local/sisis-pap/lib/libcurl.so.4.8.0 > > ... > > I have to figure out why the making of 'curl' does not produce that > symlink by its own, or why the making of pg_tde.so let it ask for > libcurl.so.4 and not for libcurl.so.4.8.0. It was not the fault in making 'curl'. It was my fault in the shell script which bundles PostgreSQL 16.2, pg_tde.so and libcurl together for delivery to other hosts/customer which only picked up the 3 files above and not also the symlinks. We can now safely close this thread. matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub
