Re: Mixing threaded and non-threaded

On Fri, Jan 23, 2004 at 10:03:30PM -0500, Bruce Momjian wrote:
> Steve Atkins wrote:
> > 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.

Yes, libpqs use of actual use of pthread seems pretty harmless.

> 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.

Exactly that, yes.

> 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.

> 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.

For now I'm just building and distributing two different libpqs and
choosing between them with rpath hacks (yes, renaming one of them
might be easier, but I'm specifying rpath explicitly anyway for other
reasons). That seems to be working just fine for me.

If there are multiple applications on the system using PostgreSQL we
really don't want to break some of them if libpq is rebuilt to support
a new one. Probably worth a mention in the documentation at least.

Cheers,
Steve