Re: BUG #17083: [PATCH] PostgreSQL fails to build with OpenLDAP 2.5.x

Поиск
Список
Период
Сортировка
От Daniel Gustafsson
Тема Re: BUG #17083: [PATCH] PostgreSQL fails to build with OpenLDAP 2.5.x
Дата
Msg-id 68D22062-EC78-47C5-BC46-EF2F77193E19@yesql.se
обсуждение исходный текст
Ответ на Re: BUG #17083: [PATCH] PostgreSQL fails to build with OpenLDAP 2.5.x  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs
> On 7 Jul 2021, at 18:57, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Adrian Ho <ml+postgresql@03s.net> writes:
>> Thanks, Tom, that turned out to only require one additional line, since
>> $LIBS is already being saved and restored around that block:
>
> I poked at this a bit further and realized that it's got a showstopper
> problem: in OpenLDAP 2.4, ldap_simple_bind() exists in both libldap.so
> and libldap_r.so.  Thus, if we were dealing with an installation that
> does not have a thread-safe libldap, the patched configure would
> incorrectly seize on libldap.so as being an acceptable substitute,
> allowing weird hard-to-diagnose failures at runtime.
>
> IOW, while it might look from our existing coding like there's something
> about ldap_simple_bind() that is tied to reentrancy, there isn't.  How
> else can we determine whether an OpenLDAP library is reentrant, if we
> can no longer depend on the _r suffix?

Couldn't we add a version check to find if we have < 2.5 or >= 2.5, and adjust
libs accordingly?  Alternatively we could perhaps check for
LDAP_API_FEATURE_X_OPENLDAP_REENTRANT which IIUC when set defines -lldap to be
reentrant.

--
Daniel Gustafsson        https://vmware.com/




В списке pgsql-bugs по дате отправления:

Предыдущее
От: Etsuro Fujita
Дата:
Сообщение: Re: The case when AsyncAppend exists also in the qual of Async ForeignScan
Следующее
От: Andrey Lepikhov
Дата:
Сообщение: Re: The case when AsyncAppend exists also in the qual of Async ForeignScan