Re: libpq thread safety - Mailing list pgsql-hackers

From Tom Lane
Subject Re: libpq thread safety
Date
Msg-id 17921.1073849527@sss.pgh.pa.us
Whole thread Raw
In response to Re: libpq thread safety  (Manfred Spraul <manfred@colorfullife.com>)
List pgsql-hackers
Manfred Spraul <manfred@colorfullife.com> writes:
> I'd agree - convince Bruce and I'll replace the mutexes in thread.c with 
> #error.

Most of what I said before was aimed at Bruce ;-)

> But I think libpq should support a mutex around kerberos (or at 
> least fail at runtime) - right now it's too easy to corrupt the kerberos 
> authentication state.

As to the first - if an app wants to support multithreaded use of
kerberos, it will have to put a mutex around uses of kerberos.  But then
it can simply extend that same mutex to uses of PQconnect.  This isn't
noticeably harder from the app's point of view than what you suggest, so
I don't see the value of cluttering our API for it.

As to the second - if there were a way to detect that the app was
actually using multiple threads, I'd agree with failing at runtime
in that case.  But otherwise this amounts to decreeing that you can't
compile with both --enable-thread-safety and --enable-kerberos, which
seems a tad too anal-retentive for my tastes.  It seems unlikely that
there'd actually be any problem with re-entrant use of kerberos, at
least compared to common libc routines like strerror.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "William ZHANG"
Date:
Subject: Re: OLE DB driver
Next
From: mgill@pointdx.com
Date:
Subject: Re: Restrict users from describing table