Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > If it is the default, libpq is going to use the libc_r library, at least
> > on some platforms, and that may not be desired.
>
> But what is the objective reason for this lack of desire?
libc_r could behave differently than libc on some platforms --- this is
the reason we don't use some semaphore stuff in pthreads in backend code
--- we don't know the ramifications.
Also, --with-threads adds threading calls to ecpg, which I am not sure
everyone would want in the default case.
> > One funny thing is that on BSD/OS and NetBSD, because there are no
> > thread compile flags, function names, or libraries, libpq is the same
> > code with or without the flag. ecpg, however, has thread calls, and is
> > effected on every platform.
>
> Well, I'm pretty sure that the current thread options are overkill and can
> be simplified. For instance, on Linux the template currently claims
No question. I just grabbed all the flags suggested. Many OS's are
going to require such tweeking.
> THREAD_CFLAGS="-D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS"
>
> _POSIX_PTHREAD_SEMANTICS isn't used anywhere in the entire system, the
> effect of _THREAD_SAFE is to define _REENTRANT, and the effect of
> _REENTRANT is to declare getlogin_r(), which PostgreSQL sources don't use.
> In other words, this can be removed.
You mean none of them are needed? Why would _REENTRANT only control
getlogin_r()? Are all the other functions thread-safe already?
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
