Steve Atkins wrote: > (I hope this is -hackers appropriate - feel free to point me elsewhere) > > I'm using 7.4.1 as the backend to several applications. Until recently, > I've been developing solely single-threaded applications. > > I just rebuilt postgresql with --enable-thread-safety, to work with > some multi-threaded code. > > When I rebuilt libpq to use threads, I started seeing a bunch of weird > failures in many of the older applications. The change in libpq meant > that libpthread was being dynamically linked into the non-thread-aware > applications, leading to some mutex deadlocks in their signal > handlers, hanging those applications. > > There doesn't seem to be any tidy way to build and use both threaded > and non-threaded libpq on the same system (LD_LIBRARY_PATH hacks > aren't really viable for distributed code). Is there something I'm > missing?
No, there is not. We could compile two versions, and have you specify the threaded version only when you want it, but only some operating systems have that distinction, so then we would have to identical libraries on some platforms, and different ones on others, and that seemed pretty confusing. Of course, we can always revisit this. > (If it's relevant, the OS in question is RedHat Linux, but I'm > maintaining the same suite of apps on several other architectures.) This is interesting. I had not considered that libpq's calls to libpthread would cause problems. In fact, libpq shouldn't be doing anything special with pthread except for a few calls used in port/thread.c. However, the issue we always were worried about was that linking against libpthread would cause some unexpected thread calls in the application, and it looks like that is exactly what you are seeing. In fact, it sounds like it is the calls to allow synchronous signals to be delivered to the thread that generated them that might be the new change you are seeing. My guess is that creating applications against the non-thread libpq and then replacing it with a threaded libpq is your 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. -- 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 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
