Re: extract properties from certificates
I could compile the pg-cert extension package, but postgresql 9.6 refused to install it. create extension cert; FEHLER: geschachteltes CREATE EXTENSION wird nicht unterstützt means "ERROR: nested CREATE EXTENSION is not supported" At line 12 in /usr/share/postgresql/9.6/extension/cert--0.1.1.sql another extension called bignum is created. As a short try, I tryed to install in seperatly. I commentent that out, git cloned the https://github.com/beargiles/pg-bignum project, make and make install leads to an error, but the extension files are available in the extensions directory: sudo make install /bin/mkdir -p '/usr/share/postgresql/9.6/extension' /bin/mkdir -p '/usr/share/postgresql/9.6/extension' /bin/mkdir -p '/usr/lib/postgresql/9.6/lib' /bin/mkdir -p '/usr/share/doc/postgresql-doc-9.6/extension' /usr/bin/install -c -m 644 .//bignum.control '/usr/share/postgresql/9.6/extension/' /usr/bin/install -c -m 644 .//sql/bignum--0.8.0.sql .//sql/bignum--0.8.0.sql '/usr/share/postgresql/9.6/extension/' /usr/bin/install: Neu erstelltes '/usr/share/postgresql/9.6/extension/bignum--0.8.0.sql' wird nicht mit './/sql/bignum--0.8.0.sql' überschrieben. /usr/lib/postgresql/9.6/lib/pgxs/src/makefiles/pgxs.mk:114: die Regel für Ziel „install“ scheiterte make: *** [install] Fehler 1 I could not create the bignum extension in my database: create extension bignum; FEHLER: konnte nicht auf Datei »bignum« zugreifen: Datei oder Verzeichnis nicht gefunden means "ERROR: could not access file "bignum": File or directory not found" Has anybody anybody an idea, how to fix this, or maybe another aproach to extract properties from X.509 certificates? Beste Regards Johannes Am 24.02.2018 um 19:07 schrieb jotpe: Am 24.02.2018 um 16:58 schrieb Tom Lane: jotpe writes: I found the pg-cert extension at https://github.com/beargiles/pg-cert I have trouble to compile it. When I enter "make" following error message appears: Makefile:29: /usr/lib/postgresql/9.6/lib/pgxs/src/makefiles/pgxs.mk: Datei oder Verzeichnis nicht gefunden make: *** Keine Regel, um „/usr/lib/postgresql/9.6/lib/pgxs/src/makefiles/pgxs.mk“ zu erstellen. Schluss. What am I missing? I'd expect pgxs.mk to be packaged in a postgresql-devel (or postgresql-dev, depending on local culture) subpackage. Maybe you didn't install that? Guessed right. postgresql-server-dev-all for debian 9 did it. Thanks. regards, tom lane
Re: extract properties from certificates
On 02/25/2018 12:26 AM, jotpe wrote: I could compile the pg-cert extension package, but postgresql 9.6 refused to install it. create extension cert; FEHLER: geschachteltes CREATE EXTENSION wird nicht unterstützt means "ERROR: nested CREATE EXTENSION is not supported" At line 12 in /usr/share/postgresql/9.6/extension/cert--0.1.1.sql another extension called bignum is created. As a short try, I tryed to install in seperatly. I commentent that out, git cloned the https://github.com/beargiles/pg-bignum project, make and make install leads to an error, but the extension files are available in the extensions directory: sudo make install /bin/mkdir -p '/usr/share/postgresql/9.6/extension' /bin/mkdir -p '/usr/share/postgresql/9.6/extension' /bin/mkdir -p '/usr/lib/postgresql/9.6/lib' /bin/mkdir -p '/usr/share/doc/postgresql-doc-9.6/extension' /usr/bin/install -c -m 644 .//bignum.control '/usr/share/postgresql/9.6/extension/' /usr/bin/install -c -m 644 .//sql/bignum--0.8.0.sql .//sql/bignum--0.8.0.sql '/usr/share/postgresql/9.6/extension/' /usr/bin/install: Neu erstelltes '/usr/share/postgresql/9.6/extension/bignum--0.8.0.sql' wird nicht mit './/sql/bignum--0.8.0.sql' überschrieben. /usr/lib/postgresql/9.6/lib/pgxs/src/makefiles/pgxs.mk:114: die Regel für Ziel „install“ scheiterte make: *** [install] Fehler 1 I could not create the bignum extension in my database: create extension bignum; FEHLER: konnte nicht auf Datei »bignum« zugreifen: Datei oder Verzeichnis nicht gefunden means "ERROR: could not access file "bignum": File or directory not found" Has anybody anybody an idea, how to fix this, or maybe another aproach to extract properties from X.509 certificates? See here: https://github.com/beargiles/pg-bignum/pull/3 in particular: https://github.com/beargiles/pg-bignum/pull/3/commits/d496a091929b15dbc0cc6ece40b0ba7bf091c8ec which changes line 21 in Makefile from DATA = $(wildcard sql/*--*.sql) sql/$(EXTENSION)--$(EXTVERSION).sql to DATA = $(wildcard sql/*--*.sql) This should eliminate this: /usr/bin/install: Neu erstelltes '/usr/share/postgresql/9.6/extension/bignum--0.8.0.sql' wird nicht mit './/sql/bignum--0.8.0.sql' überschrieben. /usr/lib/postgresql/9.6/lib/pgxs/src/makefiles/pgxs.mk:114: die Regel für Ziel „install“ scheiterte make: *** [install] Fehler 1 and allow the install to complete. Beste Regards Johannes Am 24.02.2018 um 19:07 schrieb jotpe: Am 24.02.2018 um 16:58 schrieb Tom Lane: jotpe writes: I found the pg-cert extension at https://github.com/beargiles/pg-cert I have trouble to compile it. When I enter "make" following error message appears: Makefile:29: /usr/lib/postgresql/9.6/lib/pgxs/src/makefiles/pgxs.mk: Datei oder Verzeichnis nicht gefunden make: *** Keine Regel, um „/usr/lib/postgresql/9.6/lib/pgxs/src/makefiles/pgxs.mk“ zu erstellen. Schluss. What am I missing? I'd expect pgxs.mk to be packaged in a postgresql-devel (or postgresql-dev, depending on local culture) subpackage. Maybe you didn't install that? Guessed right. postgresql-server-dev-all for debian 9 did it. Thanks. regards, tom lane -- Adrian Klaver adrian.kla...@aklaver.com
Re: extract properties from certificates
Am 25.02.2018 um 16:42 schrieb Adrian Klaver: On 02/25/2018 12:26 AM, jotpe wrote: I could compile the pg-cert extension package, but postgresql 9.6 refused to install it. create extension cert; FEHLER: geschachteltes CREATE EXTENSION wird nicht unterstützt means "ERROR: nested CREATE EXTENSION is not supported" At line 12 in /usr/share/postgresql/9.6/extension/cert--0.1.1.sql another extension called bignum is created. As a short try, I tryed to install in seperatly. I commentent that out, git cloned the https://github.com/beargiles/pg-bignum project, make and make install leads to an error, but the extension files are available in the extensions directory: sudo make install /bin/mkdir -p '/usr/share/postgresql/9.6/extension' /bin/mkdir -p '/usr/share/postgresql/9.6/extension' /bin/mkdir -p '/usr/lib/postgresql/9.6/lib' /bin/mkdir -p '/usr/share/doc/postgresql-doc-9.6/extension' /usr/bin/install -c -m 644 .//bignum.control '/usr/share/postgresql/9.6/extension/' /usr/bin/install -c -m 644 .//sql/bignum--0.8.0.sql .//sql/bignum--0.8.0.sql '/usr/share/postgresql/9.6/extension/' /usr/bin/install: Neu erstelltes '/usr/share/postgresql/9.6/extension/bignum--0.8.0.sql' wird nicht mit './/sql/bignum--0.8.0.sql' überschrieben. /usr/lib/postgresql/9.6/lib/pgxs/src/makefiles/pgxs.mk:114: die Regel für Ziel „install“ scheiterte make: *** [install] Fehler 1 I could not create the bignum extension in my database: create extension bignum; FEHLER: konnte nicht auf Datei »bignum« zugreifen: Datei oder Verzeichnis nicht gefunden means "ERROR: could not access file "bignum": File or directory not found" Has anybody anybody an idea, how to fix this, or maybe another aproach to extract properties from X.509 certificates? See here: https://github.com/beargiles/pg-bignum/pull/3 in particular: https://github.com/beargiles/pg-bignum/pull/3/commits/d496a091929b15dbc0cc6ece40b0ba7bf091c8ec which changes line 21 in Makefile from DATA = $(wildcard sql/*--*.sql) sql/$(EXTENSION)--$(EXTVERSION).sql to DATA = $(wildcard sql/*--*.sql) This should eliminate this: /usr/bin/install: Neu erstelltes '/usr/share/postgresql/9.6/extension/bignum--0.8.0.sql' wird nicht mit './/sql/bignum--0.8.0.sql' überschrieben. /usr/lib/postgresql/9.6/lib/pgxs/src/makefiles/pgxs.mk:114: die Regel für Ziel „install“ scheiterte make: *** [install] Fehler 1 and allow the install to complete. That worked. Thank you! Beste Regards Johannes Am 24.02.2018 um 19:07 schrieb jotpe: Am 24.02.2018 um 16:58 schrieb Tom Lane: jotpe writes: I found the pg-cert extension at https://github.com/beargiles/pg-cert I have trouble to compile it. When I enter "make" following error message appears: Makefile:29: /usr/lib/postgresql/9.6/lib/pgxs/src/makefiles/pgxs.mk: Datei oder Verzeichnis nicht gefunden make: *** Keine Regel, um „/usr/lib/postgresql/9.6/lib/pgxs/src/makefiles/pgxs.mk“ zu erstellen. Schluss. What am I missing? I'd expect pgxs.mk to be packaged in a postgresql-devel (or postgresql-dev, depending on local culture) subpackage. Maybe you didn't install that? Guessed right. postgresql-server-dev-all for debian 9 did it. Thanks. regards, tom lane
Re: extract properties from certificates
On 02/25/2018 10:11 AM, jotpe wrote: This should eliminate this: /usr/bin/install: Neu erstelltes '/usr/share/postgresql/9.6/extension/bignum--0.8.0.sql' wird nicht mit './/sql/bignum--0.8.0.sql' überschrieben. /usr/lib/postgresql/9.6/lib/pgxs/src/makefiles/pgxs.mk:114: die Regel für Ziel „install“ scheiterte make: *** [install] Fehler 1 and allow the install to complete. That worked. Thank you! The thanks is due to Evan Carroll: https://github.com/EvanCarroll Beste Regards Johannes -- Adrian Klaver adrian.kla...@aklaver.com
Re: == PostgreSQL Weekly News - January 28 2018 ==
On Mon, Jan 29, 2018 at 03:57:48AM +0100, David Fetter wrote: > == PostgreSQL Weekly News - January 28 2018 == ... > == Applied Patches == ... > Tom Lane pushed: ... > - In pg_dump, force reconnection after issuing ALTER DATABASE SET command(s). > The folly of not doing this was exposed by the buildfarm: in some cases, the > GUC settings applied through ALTER DATABASE SET may be essential to > interpreting the reloaded data correctly. Another argument why we can't > really get away with the scheme proposed in commit b3f840120 is that it > cannot > work for parallel restore: even if the parent process manages to hang onto > the > previous GUC state, worker processes would see the state > post-ALTER-DATABASE. > (Perhaps we could have dodged that bullet by delaying DATABASE PROPERTIES > restoration to the end of the run, but that does nothing for the data > semantics problem.) This leaves us with no solution for the > default_transaction_read_only issue that commit 4bd371f6f intended to work > around, other than "you gotta remove such settings before > dumping/upgrading". > However, in view of the fact that parallel restore broke that hack years ago > and no one has noticed, it's fair to question how many people care. I do (I am OP from the original report). The reason no one's noticed is that so far Debian's pg_upgradecluster doesn't by default seem to use more than one job for restore (it does use pg_dump/pg_restore over pg_upgrade by default). > I'm unexcited about adding a large dollop of new complexity to handle that > corner > case. This would be a one-liner fix, except it turns out that > ReconnectToServer tries to optimize away "redundant" reconnections. While > that may have been valuable when coded, a quick survey of current callers > shows that there are no cases where that's actually useful, so just remove > that check. While at it, remove the function's useless return value. > Discussion: https://postgr.es/m/12453.1516655...@sss.pgh.pa.us > > https://git.postgresql.org/pg/commitdiff/160a4f62ee7b8a96984f8bef19c90488aa6c8045 However, reading _this_ commit message ... > - Move handling of database properties from pg_dumpall into pg_dump. This > patch > rearranges the division of labor between pg_dump and pg_dumpall so that > pg_dump itself handles all properties attached to a single database. > Notably, > a database's ACL (GRANT/REVOKE status) and local GUC settings established by > ALTER DATABASE SET and ALTER ROLE IN DATABASE SET can be dumped and restored > by pg_dump. This is a long-requested improvement. "pg_dumpall -g" will now > produce only role- and tablespace-related output, nothing about individual > databases. The total output of a regular pg_dumpall run remains the same. > pg_dump (or pg_restore) will restore database-level properties only when > creating the target database with --create. This applies not only to ACLs > and > GUCs but to the other database properties it already handled, that is > database > comments and security labels. This is more consistent and useful, but does > represent an incompatibility in the behavior seen without --create. (This > change makes the proposed patch to have pg_dump use "COMMENT ON DATABASE > CURRENT_DATABASE" unnecessary, since there is no case where the command is > issued that we won't know the true name of the database. We might still > want > that patch as a feature in its own right, but pg_dump no longer needs it.) > pg_dumpall with --clean will now drop and recreate the "postgres" and > "template1" databases in the target cluster, allowing their locale and > encoding settings to be changed if necessary, and providing a cleaner way to > set nondefault tablespaces for them than we had before. This means that > such > a script must now always be started in the "postgres" database; the order of > drops and reconnects will not work otherwise. Without --clean, the script > will not adjust any database-level properties of those two databases > (including their comments, ACLs, and security labels, which it formerly > would > try to set). Another minor incompatibility is that the CREATE DATABASE > commands in a pg_dumpall script will now always specify locale and encoding > settings. Formerly those would be omitted if they matched the cluster's > default. While that behavior had some usefulness in some migration > scenarios, > it also posed a significant hazard of unwanted locale/encoding changes. To > migrate to another locale/encoding, it's now necessary to use pg_dump > without > --create to restore into a database with the desired settings. Commit > 4bd371f6f's hack to emit "SET default_transaction_read_only = off" is gone: > we > now dodge that problem by the expedient of not issuing ALTER DATABASE SET > commands until after reconnecting to the target database. Therefore, such > settings won't
pg_dumpall SET default_transaction_read_only = off (was Re: == PostgreSQL Weekly News - January 28 2018 ==)
Karsten Hilbert writes: > On Mon, Jan 29, 2018 at 03:57:48AM +0100, David Fetter wrote: >> Tom Lane pushed: >> ... This leaves us with no solution for the >> default_transaction_read_only issue that commit 4bd371f6f intended to work >> around, other than "you gotta remove such settings before dumping/upgrading". >> However, in view of the fact that parallel restore broke that hack years ago >> and no one has noticed, it's fair to question how many people care. > I do (I am OP from the original report). The reason no one's > noticed is that so far Debian's pg_upgradecluster doesn't by > default seem to use more than one job for restore (it does > use pg_dump/pg_restore over pg_upgrade by default). > However, reading _this_ commit message ... >> ... Commit >> 4bd371f6f's hack to emit "SET default_transaction_read_only = off" is gone: >> we >> now dodge that problem by the expedient of not issuing ALTER DATABASE SET >> commands until after reconnecting to the target database. > ... am I right in assuming my use case (dumping/restoring > databases with default_transaction_read_only=True) should > still work without removing that setting beforehand ? No; you're reading the commits in reverse order. The hack I thought we could use to preserve that behavior didn't work. AFAICS, the only way we could maintain something like the old behavior here is to promote it to a full-fledged feature, something like a pg_dump/pg_restore option "--ignore-read-only" to make those programs issue "SET default_transaction_read_only = off" at the right times, which in turn would need to be invoked by a similar pg_dumpall switch. (You could maybe argue for having pg_dumpall invoke that by default, but if we're going this far we might as well go the extra mile and make it switchable all the way down. One of the ways in which this was a hack, IMO, was that there wasn't a switch required to enable it. The argument that this behavior is always appropriate for pg_dumpall but never for pg_dump seems pretty thin to me.) While that doesn't seem like it would be terribly hard to do, I don't personally have the interest to go do it. regards, tom lane
Re: pg_dumpall SET default_transaction_read_only = off (was Re: == PostgreSQL Weekly News - January 28 2018 ==)
On Sun, Feb 25, 2018 at 04:20:41PM -0500, Tom Lane wrote:
> No; you're reading the commits in reverse order. The hack I thought we
> could use to preserve that behavior didn't work.
>
> AFAICS, the only way we could maintain something like the old behavior
> here is to promote it to a full-fledged feature, something like a
> pg_dump/pg_restore option "--ignore-read-only" to make those programs
> issue "SET default_transaction_read_only = off" at the right times,
> which in turn would need to be invoked by a similar pg_dumpall switch.
...
> While that doesn't seem like it would be terribly hard to do, I don't
> personally have the interest to go do it.
OK, I see.
Luckily, pg_upgradecluster allows running custom snippets at
appropriate times during the upgrade:
HOOK SCRIPTS
Some PostgreSQL extensions like PostGIS need metadata in
auxiliary tables which must not be upgraded from the old
version, but rather initialized for the new version
before copying the table data. For this purpose,
extensions (as well as administrators, of course) can
drop upgrade hook scripts into
/etc/postgresql-common/pg_upgradecluster.d/. Script file
names must consist entirely of upper and lower case
letters, digits, underscores, and hyphens; in particular,
dots (i. e. file extensions) are not allowed.
Scripts in that directory will be called with the following arguments:
Phases:
init
A virgin cluster of version new version has been
created, i. e. this new cluster will already have
template1 and postgres, but no user databases.
Please note that you should not create tables in
this phase, since they will be overwritten by the
dump/restore or pg_upgrade operation.
finish
All data from the old version cluster has been
dumped/reloaded into the new one. The old cluster
still exists, but is not running.
Failing scripts will abort the upgrade. The scripts
are called as the user who owns the database.
which will allow solving the problem with something like the
attached sript.
Karsten
--
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
#!/bin/sh
#==
#
# This script modifies the GNUmed databases such that an
# upgrade using Debian's may succeed.
#
# Drop this file into /etc/postgresql-common/pg_upgradecluster.d/
# if you are using a postgresql-common package < v122 on Debian
# and want to upgrade your cluster using .
#
# Note that pg_upgradecluster will run this as user .
#
# author: Karsten Hilbert
# license: GPL v2 or later
#==
DB_VERSIONS="2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20"
#==
# There really should not be any need to
# change anything below this line.
#==
# read data from pg_upgradecluster API
OLD_VER="$1"
CLUSTER_NAME="$2"
NEW_VER="$3"
PHASE="$4"
# appropriate phase ?
if test "${PHASE}" = "init" ; then
echo " - removing readonly attribute from GNUmed databases..."
ACTION="off"
elif test "${PHASE}" = "finish" ; then
echo " - re-adding readonly attribute to GNUmed databases..."
ACTION="on"
else
echo "INVALID pg_upgrade PHASE: <${PHASE}>";
exit 1;
fi
# setup files
TS=`date +%Y-%m-%d-%H-%M-%S`
SQL_FILE="/tmp/gm-pg_upgradecluster-helper-readonly_${ACTION}-${TS}.sql"
LOG_FILE="/tmp/gm-pg_upgradecluster-helper-readonly_${ACTION}-${TS}.log"
# create SQL script
echo "\\unset ON_ERROR_STOP" > ${SQL_FILE}
for DB_VER in ${DB_VERSIONS} ; do
echo "" >> ${SQL_FILE}
echo "BEGIN;" >> ${SQL_FILE}
echo "ALTER DATABASE \"gnumed_v${DB_VER}\" SET
default_transaction_read_only TO ${ACTION};" >> ${SQL_FILE}
echo "END;" >> ${SQL_FILE}
done
# get port of OLD cluster as suggested by pg_upgradecluster maintainer
CMD="use PgCommon; \$p = get_cluster_port \"${OLD_VER}\", \"${CLUSTER_NAME}\";
print \"\$p\\n\""
PORT=`perl -I/usr/share/postgresql-common/ -e "$CMD"`
# run SQL script against OLD cluster
echo "Accessing port: ${PORT}" > ${LOG_FILE} 2>&1
psql -p ${PORT} -f ${SQL_FILE} >> ${LOG_FILE} 2>&1
# also run it against NEW cluster on finish
if test "${PHASE}" = "finish" ; then
CMD="use PgCommon; \$p = get_cluster_port \"${NEW_VER}\",
\"${CLUSTER_NAME}\"; print \"\$p\\n\""
PORT=`perl -I/usr/share/postgresql-common/ -e "$CMD"`
echo "Accessing port: ${PORT}" >> ${LOG_FILE} 2>&1
psql -p ${PORT} -f ${SQL_FILE} >> ${LOG_FILE} 2>&1;
fi
exit 0
is libpq and openssl 1.1.* compatible?
I got the latest libpq (from pg 10.1), and tried to compile it with openssl 1.1. I got errors: libpq10\fe-secure-openssl.c(1582): error C2037: left of 'ptr' specifies undefined struct/union 'bio_st' libpq10\fe-secure-openssl.c(1582): error C2198: 'pqsecure_raw_read' : too few arguments for call libpq10\fe-secure-openssl.c(1612): error C2037: left of 'ptr' specifies undefined struct/union 'bio_st' libpq10\fe-secure-openssl.c(1612): error C2198: 'pqsecure_raw_write' : too few arguments for call libpq10\fe-secure-openssl.c(1671): error C2027: use of undefined type 'bio_method_st' openssl-1.1.0g\inc32\openssl\bio.h(244) : see declaration of 'bio_method_st' libpq10\fe-secure-openssl.c(1674): error C2027: use of undefined type 'bio_method_st' I wonder if I'm not doing smth right, or libpq is not compatible with openssl 1.1? Please help. Thank you!
Re: is libpq and openssl 1.1.* compatible?
On 02/25/2018 08:36 PM, Konstantin Izmailov wrote: I got the latest libpq (from pg 10.1), and tried to compile it with openssl 1.1. I got errors: libpq10\fe-secure-openssl.c(1582): error C2037: left of 'ptr' specifies undefined struct/union 'bio_st' libpq10\fe-secure-openssl.c(1582): error C2198: 'pqsecure_raw_read' : too few arguments for call libpq10\fe-secure-openssl.c(1612): error C2037: left of 'ptr' specifies undefined struct/union 'bio_st' libpq10\fe-secure-openssl.c(1612): error C2198: 'pqsecure_raw_write' : too few arguments for call libpq10\fe-secure-openssl.c(1671): error C2027: use of undefined type 'bio_method_st' openssl-1.1.0g\inc32\openssl\bio.h(244) : see declaration of 'bio_method_st' libpq10\fe-secure-openssl.c(1674): error C2027: use of undefined type 'bio_method_st' I wonder if I'm not doing smth right, or libpq is not compatible with openssl 1.1? Please help. Where did you get the libpq source from? What was the command you used to compile? Do you have openssl-dev(el) installed? Thank you! -- Adrian Klaver adrian.kla...@aklaver.com
Re: is libpq and openssl 1.1.* compatible?
On Sun, Feb 25, 2018 at 09:06:39PM -0800, Adrian Klaver wrote: > On 02/25/2018 08:36 PM, Konstantin Izmailov wrote: >> I wonder if I'm not doing smth right, or libpq is not compatible with >> openssl 1.1? Please help. The answer to the second question is that libpq is compatible with OpenSSL 1.1.0 since this commit: commit: 593d4e47db7af1a3a5dd6b6b1971f181b5566dbd author: Heikki Linnakangas date: Thu, 15 Sep 2016 14:42:29 +0300 Support OpenSSL 1.1.0. This applies down to 9.5. Porting got a bit more difficult with 9.4 and older versions. As 1.0.2 is LTS, meaning that it will become EOL after 1.1.0, porting 1.1.0 does not matter much as most application are going to use 1.0.2 in priority (I do so for one). > Do you have openssl-dev(el) installed? Most likely that's the problem. Debian does this package split for example. -- Michael signature.asc Description: PGP signature
Re: is libpq and openssl 1.1.* compatible?
Let me ask this differently: can Visual Studio 2013/2017 compile libpq with openssl 1.1 support? Under Windows? I have not been able to find an answer by googling before asking this question here. Can someone share the compiled library and changes in the source if needed for the openssl 1.1? Magnus please. On Sun, Feb 25, 2018 at 10:44 PM, Michael Paquier wrote: > On Sun, Feb 25, 2018 at 09:06:39PM -0800, Adrian Klaver wrote: > > On 02/25/2018 08:36 PM, Konstantin Izmailov wrote: > >> I wonder if I'm not doing smth right, or libpq is not compatible with > >> openssl 1.1? Please help. > > The answer to the second question is that libpq is compatible with > OpenSSL 1.1.0 since this commit: > commit: 593d4e47db7af1a3a5dd6b6b1971f181b5566dbd > author: Heikki Linnakangas > date: Thu, 15 Sep 2016 14:42:29 +0300 > Support OpenSSL 1.1.0. > > This applies down to 9.5. Porting got a bit more difficult with 9.4 and > older versions. As 1.0.2 is LTS, meaning that it will become EOL after > 1.1.0, porting 1.1.0 does not matter much as most application are going > to use 1.0.2 in priority (I do so for one). > > > Do you have openssl-dev(el) installed? > > Most likely that's the problem. Debian does this package split for > example. > -- > Michael >
