Sumit Chaturvedi <sumit.chaturvedi@xxxxxxxxx> writes: > So although the problem is with xcode. I have a feeling that it is not > because of LC_ALL. > So my point is that maybe the hint is not entirely correct.. At the time that HINT was written, the only reason we knew of for a production postmaster to become multithreaded under macOS was for libintl to start an extra thread while trying to find out the default locale. That could be prevented by setting LC_ALL, hence the hint. I wonder whether starting the postmaster under xcode inherently causes extra threads to be present (for debugging?). There are quite a number of PG developers who use Macs, including me, but I don't use xcode for PG and I think others don't either. In any case, I concur with the upthread advice not to take out the anti-multithreading check. The postmaster will not work reliably if there are extra threads in it, so you'd just be dooming yourself to crashes and frustration. Usually the thing you want to trace is not the postmaster anyway, but some session backend. The best bet is to start the postmaster normally, start psql or your other client of choice, then identify which backend process is connected to that client and attach to it with gdb/lldb. Perhaps xcode can do an "attach to running process", though at this point I'm wondering if it starts extra threads when it does so. regards, tom lane
