Re: LDAP authenticated session terminated by signal 11: Segmentation fault, PostgresSQL server terminates other active server processes

From: Mike Yeap <wkk1020(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, pgsql-general(at)postgresql(dot)org
Subject: Re: LDAP authenticated session terminated by signal 11: Segmentation fault, PostgresSQL server terminates other active server processes
Date: 2019-02-21 01:42:04
Message-ID: CAMVYW_6XyjFM1JCg3Rs32ocFZf_zHqhyxQcnx8mrFsnxDm-1uA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

> 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 <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)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 <noah(at)leadboat(dot)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
>

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2019-02-21 02:03:29 Re: LDAP authenticated session terminated by signal 11: Segmentation fault, PostgresSQL server terminates other active server processes
Previous Message Ron 2019-02-21 00:40:54 Re: Copy entire schema A to a different schema B