Re: LDAP authenticated session terminated by signal 11: Segmentationfault, PostgresSQL server terminates other active server processes
От | Thomas Munro |
---|---|
Тема | Re: LDAP authenticated session terminated by signal 11: Segmentationfault, PostgresSQL server terminates other active server processes |
Дата | |
Msg-id | CA+hUKG+cH_c7oBDROdLMF1k1Lt0H-UyAAm5dWxri531bGQUbeg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: LDAP authenticated session terminated by signal 11: Segmentation fault, PostgresSQL server terminates other active server processes (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: LDAP authenticated session terminated by signal 11: Segmentationfault, PostgresSQL server terminates other active server processes
|
Список | pgsql-general |
Adding Noah to thread. On Wed, Feb 27, 2019 at 11:28 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Thomas Munro <thomas.munro@gmail.com> writes: > > I don't see pthread_is_threaded_np() on any non-Apple systems in my > > lab. > > Yeah, I thought that might be a Mac thing. I wonder if POSIX has any > usable equivalent. I don't see anything like that (the concept doesn't seem very portable). I couldn't find a way on Glibc (but I'm not saying there isn't one hiding somewhere). FreeBSD has a thing much like macOS's (and I think some more BSDs do too); it's set to true by libthr when the first thread is created, to make libc start locking various stuff. The macOS one probably isn't a good canary to protect us from OpenLDAP creating threads since on typical macOS builds we're using Apple's LDAP thing (which cybersquats libldap.dylib and libldap_r.dylib via symlinks). So adding a FreeBSD check seems like a good idea, because at least one FreeBSD system in our buildfarm runs the ldap checks on real OpenLDAP (elver). > > Clearly libdap_r is *capable* of creating threads: it contains a > > function ldap_pvt_thread_create(), and we can see that slapd and other > > OpenLDAP things use that, but AFAICT that's a private facility not > > intended for end users to call, so there's no danger if you just use > > the documented LDAP client API. > > That seems promising, but I'd sure be happier if we could cross-check > that there's still just one thread at the completion of authentication. Ok, here's that patch again with a commit message and with the configure version warning removed, and a make-sure-we're-not-threaded patch for FreeBSD. I'm not sure what to do about the LDAP test in contrib/dblink/sql/dblink.sql. Do we still want this? 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. -- Thomas Munro https://enterprisedb.com
Вложения
В списке pgsql-general по дате отправления: