On Thu, Mar 7, 2019 at 4:19 PM Noah Misch <noah@xxxxxxxxxxxx> 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). I tried "make check" in contrib/dblink, and the only strange thing I noticed was this FATAL error at the top of contrib/dblink/log/postmaster.log: 2019-03-14 03:51:33.058 UTC [20131] LOG: database system is ready to accept connections 2019-03-14 03:51:33.059 UTC [20135] [unknown] FATAL: the database system is starting up I don't see that on other systems and don't understand it. I also tried a test of my own which I thought corresponded directly to what Mike described, on both master and REL_10_STABLE. I'll record my steps here so perhaps someone can see what's missing. 1. Run the regression test under src/test/ldap so that you get some canned slapd configuration files. 2. cd into src/test/ldap/tmp_check and run "slapd -f slapd.conf -h ldap://localhost:5555";. It should daemonify itself, and run until you kill it with SIGINT. 3. Put this into pg_hba.conf: host postgres test1 127.0.0.1/32 ldap ldapserver=localhost ldapport=5555 ldapbasedn="dc=example,dc=net" 4. Create database objects as superuser: create user test1; create table t (i int); grant all on t to test1; create extension postgres_fdw; create server foreign_server foreign data wrapper postgres_fdw options (dbname 'postgres', host '127.0.0.1'); create foreign table ft (i int) server foreign_server options (table_name 't'); create user mapping for test1 server foreign_server options (user 'test1', password 'secret1'); grant all on ft to test1; 5. Now you should be able to log in with "psql -h 127.0.0.1 postgres test1" and password "secret1", and run queries like: select * from ft; 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? > > I propose this for master only, for now. I also think it'd be nice to > > consider back-patching it after a while, especially since this > > reported broke on CentOS/RHEL7, a pretty popular OS that'll be around > > for a good while. Hmm, I wonder if it's OK to subtly change library > > dependencies in a minor release; I don't see any problem with it since > > I expect both variants to be provided by the same package in every > > distro but we'd certainly want to highlight this to the package > > maintainers if we did it. > > It's not great to change library dependencies in a minor release. If every > RHEL 7 installation can crash this way, changing the dependencies is probably > the least bad thing. +1, once we get a repro and/or better understanding. -- Thomas Munro https://enterprisedb.com
