Thomas Munro <thomas.munro@xxxxxxxxx> writes: > On Wed, Mar 20, 2019 at 10:51 AM Tom Lane <tgl@xxxxxxxxxxxxx> 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
