Steve Atkins wrote: > > My guess is that creating applications against the non-thread libpq and > > then replacing it with a threaded libpq is your problem. > > Yes. It seems to make no difference whether the application is rebuilt > or not. It's pulling libpthread into a non-thread-aware application > that's the problem. > > The only fix that would allow the non-threaded application to work > with a thread-safe libpq would be to rewrite it to be a threaded > application with a single active thread.
Woh, as far as I know, any application should run fine with -lpthread, threaded or not. What OS are you on? This is the first I have heard of this problem. > > I guess the > > question is whether you would like to have two libpq's and have to > > decide at link time if you wanted threading, or just have one libpq and > > make sure you recompile if you change the threading behavior of the > > library. We considered the later to be clearer. > > Recompiling doesn't neccesarily help unless the application is also > rewritten. Also, if there are dozens of non-threaded applications > using libpq on a system (possibly installed via rpms or equivalent) > then replacing the system libpq could break something else. Why? How would you rewrite it? -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
