Hi Thomas, does that mean the bug is still there?
Regards,
Mike Yeap
On Mon, Feb 25, 2019 at 4:06 PM Thomas Munro <thomas.munro@xxxxxxxxx> wrote:
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
