Hi,
On 2022-08-29 23:18:23 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Why do we continue to link the backend to ldap when we find ldap_r, given
> > that
> > we know that it can cause problems for extension libraries using libpq?
>
> Uh ... if we know that, it's news to me.
Isn't that wh
Andres Freund writes:
> Why do we continue to link the backend to ldap when we find ldap_r, given that
> we know that it can cause problems for extension libraries using libpq?
Uh ... if we know that, it's news to me.
I think we might've avoided ldap_r for fear of pulling libpthread into
the bac
Hi,
On 2022-05-06 14:00:43 -0400, Tom Lane wrote:
> I wrote:
> > Oh, I have a theory about this: I bet your Homebrew installation
> > has a recent OpenLDAP version that only supplies libldap not libldap_r.
> > In that case, configure will still find libldap_r available and will
> > bind libpq to i
I wrote:
> OK. I will push the configure change once the release freeze lifts.
And done.
regards, tom lane
Peter Eisentraut writes:
> Btw., I was a bit puzzled about all this talk about deprecation
> warnings, which I have not seen. I turns out that you only get those if
> you use the OS compiler, not a third-party gcc installation.
Ah-hah.
> So in terms of my original message, my installation is
On 04.05.22 17:16, Tom Lane wrote:
Hmm, I just tried it with up-to-date MacPorts, and it was a*complete*
fail: I got all the deprecation warnings (so the system include headers
were used), and both postgres and libpq.dylib still ended up linked
against /System/Library/Frameworks/LDAP.framework/Ve
On 06.05.22 21:25, Tom Lane wrote:
I wrote:
After thinking about this for awhile, it seems like the best solution
is to make configure proceed like this:
1. Find libldap.
2. Detect whether it's OpenLDAP 2.5 or newer.
3. If not, try to find libldap_r.
Here's a proposed patch for that. It se
I wrote:
> After thinking about this for awhile, it seems like the best solution
> is to make configure proceed like this:
> 1. Find libldap.
> 2. Detect whether it's OpenLDAP 2.5 or newer.
> 3. If not, try to find libldap_r.
Here's a proposed patch for that. It seems to do the right thing
with
I wrote:
> We still have a bit of work to do, because this setup isn't getting
> all the way through src/test/ldap/:
> 2022-05-04 11:01:33.459 EDT [21304] LOG: server process (PID 21312) was
> terminated by signal 11: Segmentation fault: 11
> Many of the test cases pass, but it looks like ldaps-r
I wrote:
> Oh, I have a theory about this: I bet your Homebrew installation
> has a recent OpenLDAP version that only supplies libldap not libldap_r.
> In that case, configure will still find libldap_r available and will
> bind libpq to it, and you get the observed result. The configure
> check is
I wrote:
> Peter Eisentraut writes:
>> I tried building with Homebrew-supplied openldap. What ends up
>> happening is that the postgres binary is indeed linked with openldap,
>> but libpq still is linked against the OS-supplied LDAP framework.
>> (Checked with "otool -L" in each case.) Can so
Peter Eisentraut writes:
> On 02.05.22 16:03, Tom Lane wrote:
>> I'm not that excited about getting rid of this warning, because to the
>> extent that anyone notices it at all, it'll motivate them to get OpenLDAP
>> from Homebrew or MacPorts, which seems like a good thing.
> I tried building with
On 02.05.22 16:03, Tom Lane wrote:
I'm not that excited about getting rid of this warning, because to the
extent that anyone notices it at all, it'll motivate them to get OpenLDAP
from Homebrew or MacPorts, which seems like a good thing.
I tried building with Homebrew-supplied openldap. What e
Peter Eisentraut writes:
> configure can report this:
> configure: WARNING:
> *** With OpenLDAP versions 2.4.24 through 2.4.31, inclusive, each backend
> *** process that loads libpq (via WAL receiver, dblink, or postgres_fdw) and
> *** also uses LDAP will crash on exit.
> I wonder whether we can
configure can report this:
configure: WARNING:
*** With OpenLDAP versions 2.4.24 through 2.4.31, inclusive, each backend
*** process that loads libpq (via WAL receiver, dblink, or postgres_fdw) and
*** also uses LDAP will crash on exit.
The source code also says
# PostgreSQL sometimes loads lib
15 matches
Mail list logo
