Sumit Chaturvedi <sumit.chaturvedi@gmail.com> 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