On Thu, Feb 21, 2019 at 2:42 PM Mike Yeap <wkk1020@xxxxxxxxx> wrote: > 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 > On Wed, Feb 20, 2019 at 10:17 PM Tom Lane <tgl@xxxxxxxxxxxxx> wrote: >> 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). Clearly 2.4.44 is not in the range 2.4.24 through 2.4.31. Perhaps the dangerous range is out of date? Hmm, so Noah's analysis[1] says this is a clash between libldap_r.so (used by libpq) and libldap.so (used by the server), specifically in destructor/exit code. Curiously, in a thread about Curl's struggles with this problem, I found a claim[2] that Debian decided to abandon the non-"_r" variant and just use _r always. Sure enough, on my Debian buster VM I see a symlink libldap-2.4.so.2 -> libldap_r-2.4.so.2. So essentially Debian and friends have already forced Noah's first option on users: > 1. Link the backend with libldap_r, so we never face the mismatch. On some > platforms, this means also linking in threading libraries. FreeBSD and CentOS systems near me have separate libraries still. [1] https://www.postgresql.org/message-id/flat/20140612210219.GA705509%40tornado.leadboat.com [2] https://www.openldap.org/lists/openldap-technical/201608/msg00094.html -- Thomas Munro https://enterprisedb.com
