> Are the "postgres" executable and libpq linked with the same version of
OpenLDAP?
How should I check whether they are linked?

My Postgres version is 10.6 and I have this output for "yum list | grep
ldap | sort":
$ yum list | grep ldap | sort

apr-util-ldap.x86_64                        1.5.2-6.el7                base
bind-dyndb-ldap.x86_64                      11.1-4.el7                 base
compat-openldap.i686                        1:2.3.43-5.el7             base
compat-openldap.x86_64                      1:2.3.43-5.el7             base
cyrus-sasl-ldap.i686                        2.1.26-23.el7              base
cyrus-sasl-ldap.x86_64                      2.1.26-23.el7              base
freeradius-ldap.x86_64                      3.0.13-9.el7_5             base
ipsilon-authldap.noarch                     1.0.0-13.el7_3             base
krb5-server-ldap.x86_64                     1.15.1-37.el7_6
updates
ldapjdk-javadoc.noarch                      4.19-5.el7                 base
ldapjdk.noarch                              4.19-5.el7                 base
mod_ldap.x86_64                             2.4.6-88.el7.centos        base
nss-pam-ldapd.i686                          0.8.13-16.el7              base
nss-pam-ldapd.x86_64                        0.8.13-16.el7              base
openldap-clients.x86_64                     2.4.44-21.el7_6
@updates
openldap-devel.i686                         2.4.44-21.el7_6
updates
openldap-devel.x86_64                       2.4.44-21.el7_6
updates
openldap.i686                               2.4.44-21.el7_6
updates
openldap-servers-sql.x86_64                 2.4.44-21.el7_6
updates
openldap-servers.x86_64                     2.4.44-21.el7_6
updates
openldap.x86_64                             2.4.44-21.el7_6
@updates
openssh-ldap.x86_64                         7.4p1-16.el7               base
php-ldap.x86_64                             5.4.16-46.el7              base
python-ldap2pg-doc.x86_64                   4.11-1.rhel7
 pgdg10
python-ldap2pg.x86_64                       4.11-1.rhel7
 pgdg10
python-ldap.x86_64                          2.4.15-2.el7               base
sssd-ldap.x86_64                            1.16.2-13.el7_6.5
updates

And in the database where I encountered this issue I have these extensions
installed:

repdb=# \dx
                                      List of installed extensions
        Name        | Version |   Schema   |
Description
--------------------+---------+------------+------------------------------------------------------------
 hstore             | 1.4     | public     | data type for storing sets of
(key, value) pairs
 pg_stat_statements | 1.6     | repdb      | track execution statistics of
all SQL statements executed
 plpgsql            | 1.0     | pg_catalog | PL/pgSQL procedural language
 postgres_fdw       | 1.0     | repdb      | foreign-data wrapper for
remote PostgreSQL servers
 tablefunc          | 1.0     | repdb      | functions that manipulate
whole tables, including crosstab
(5 rows)

Thank you.

Regards,
Mike Yeap

On Wed, Feb 20, 2019 at 10:17 PM Tom Lane <t...@sss.pgh.pa.us> wrote:

> Laurenz Albe <laurenz.a...@cybertec.at> writes:
> > Mike Yeap wrote:
> >> I have encountered a problem related to LDAP authenticated session with
> Postgres foreign data wrapper (postgres_fdw).
>
> > Are the "postgres" executable and libpq linked with the same version of
> OpenLDAP?
>
> And which version is that?  (And which version of Postgres?)
>
> Digging around in our git history, I came across this:
>
> Author: Noah Misch <n...@leadboat.com>
> Branch: master Release: REL9_5_BR [d7cdf6ee3] 2014-07-22 11:01:03 -0400
>
>     Diagnose incompatible OpenLDAP versions during build and test.
>
>     With OpenLDAP versions 2.4.24 through 2.4.31, inclusive, PostgreSQL
>     backends can crash at exit.  Raise a warning during "configure" based
> on
>     the compile-time OpenLDAP version number, and test the crash scenario
> in
>     the dblink test suite.  Back-patch to 9.0 (all supported versions).
>
> which sounds a fair bit like what you are describing.
>
>                         regards, tom lane
>

Reply via email to