Re: Mixing threaded and non-threaded

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
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073