Thomas Munro <thomas.munro@gmail.com> writes:
> On Wed, Mar 20, 2019 at 10:51 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> It's reasonable to assume that the proposed patch won't cause real issues
>> on any modern platform, but I'm not sure we can assume that for old ones,
>> so the whole thing is making me a bit nervous.
> Sure, it's possible that some BF animal will fail to link the backend
> for some reason that requires a bit of investigation and a follow-up
> patch. Are you thinking of systems not covered by the BF?
No, I'm thinking that a "followup patch" might be impossible.
> Unless the server is being built with an extremely small set of
> configure options enabled, it's almost certainly already linking
> something that pulls in the platform's threading library (SSL, GSSAPI,
> XML2, ...).
Yeah, but if somebody is relying on LDAP and not any of those other
things, they won't be happy.
> If someone out there is not enabling any of that stuff
> because their system doesn't like threads, they can use
> --disable-thread-safety to avoid the effects of this change.
No, that's nonsense; --disable-thread-safety only affects what happens
on the frontend side.
>> As far as the specifics of the patch go, I don't like that you didn't
>> adjust any of the comments near pthread_is_threaded_np() usages.
> Hmm. The comments seemed OK to me without adjustment, is there
> something specific that bothered you?
The comment at postmaster.c:1339 is very specific about how there's
a problem with macOS's libintl. On the basis of that, nobody would
expect that there's a need to do anything on any other platform.
I think we should at least add something about how we're worried
about libldap_r maybe causing the backend to become multithreaded.
> The errhint about LC_ALL is
> wrong though, it's macOS-specific.
Yeah, but that's part and parcel with the comment.
regards, tom lane
