On Thu, Mar 14, 2019 at 05:18:49PM +1300, Thomas Munro wrote:
> On Thu, Mar 7, 2019 at 4:19 PM Noah Misch <noah@leadboat.com> wrote:
> > Has anyone else reproduced this?
>
> I tried, but could not reproduce this problem on "CentOS Linux release
> 7.6.1810 (Core)" using OpenLDAP "2.4.44-21.el7_6" (same as Mike
> reported, what yum install is currently serving up).
> When exiting the session, I was expecting the backend to crash,
> because it had executed libldap.so code during authentication, and
> then it had linked in libldap_r.so via libpq.so while connecting via
> postgres_fdw. But it doesn't crash. I wonder what is different for
> Mike; am I missing something, or is there non-determinism here?
The test is deterministic. I'm guessing Mike's system is finding ldap
libraries other than the usual system ones. Mike, would you check as follows?
$ echo "select pg_backend_pid(); load 'dblink'; select pg_sleep(100)" | psql -X &
[1] 2530123
pg_backend_pid
----------------
2530124
(1 row)
LOAD
$ gdb --batch --pid 2530124 -ex 'info sharedlibrary ldap'
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
0x00007ffff6303463 in __epoll_wait_nocancel () from /lib64/libc.so.6
From To Syms Read Shared Object Library
0x00007ffff65e1ee0 0x00007ffff6613304 Yes (*) /lib64/libldap-2.4.so.2
0x00007fffe998f6d0 0x00007fffe99c3ae4 Yes (*) /lib64/libldap_r-2.4.so.2
(*): Shared library is missing debugging information.