Tom Lane wrote:
> Manfred Spraul <[EMAIL PROTECTED]> writes:
> > But what about kerberos: I'm a bit reluctant to add a forth mutex: what
> > if kerberos calls gethostbyname or getpwuid internally?
>
> Wouldn't help anyway, if some other part of the app also calls kerberos.
> I think we should jus
Bruce Momjian wrote:
How can we test if libpq needs to call that? Seems that is an issue
whether we are threaded or not, no?
I think it's always an issue: in the non-threaded case, it's just not
fatal. At least some openssl init functions are protected with "if
(done) return; done = 1;", and
Patch withdrawn by author.
---
Manfred Spraul wrote:
> Bruce Momjian wrote:
>
> >What killed the idea of doing ssl or kerberos locking inside libpq was
> >that there was no way to be sure that outside code didn't also acces
Bruce Momjian wrote:
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
You are too fast: the patch was a proof of concept, not really tested
(actually quite buggy).
Attached
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Manfred Spraul wrote:
> Bruce Momjian wro
Manfred Spraul wrote:
> Bruce Momjian wrote:
>
> >What killed the idea of doing ssl or kerberos locking inside libpq was
> >that there was no way to be sure that outside code didn't also access
> >those routines.
> >
> A callback based implementation can handle that: libpq has a default
> impleme
Bruce Momjian wrote:
What killed the idea of doing ssl or kerberos locking inside libpq was
that there was no way to be sure that outside code didn't also access
those routines.
A callback based implementation can handle that: libpq has a default
implementation for apps that do not use openssl or
Bruce Momjian wrote:
> Manfred Spraul wrote:
> > Hi,
> >
> > I've searched through libpq and looked for global or static variables as
> > indicators of non-threadsafe code. I found:
> > - Win32 and BeOS: there is a global "ioctlsocket_ret variable, but it
> > seems to be a dummy variable that is
Manfred Spraul wrote:
> libpq needs additional changes for complete thread safety:
> - openssl needs different initialization.
> - kerberos is not thread safe.
> - functions such as gethostbyname are not thread safe, and could be used
> by kerberos. Right now protected with a libpq specific mutex
Manfred Spraul wrote:
> Bruce Momjian wrote:
>
> >However, we really have two types of function tested.
> >The first, strerror, can be thread safe by using thread-local storage
> >_or_ by returning pointers to static strings. The other two function
> >tests require thread-local storage to be thr
Bruce Momjian wrote:
However, we really have two types of function tested.
The first, strerror, can be thread safe by using thread-local storage
_or_ by returning pointers to static strings. The other two function
tests require thread-local storage to be thread-safe.
You are completely ignori
Manfred Spraul wrote:
> Tom Lane wrote:
>
> >Wait a minute. I am *not* buying into any proposal that we need to
> >support ENABLE_THREAD_SAFETY on machines where libc is not thread-safe.
> >We have other things to do than adopt an open-ended commitment to work
> >around threading bugs on obsolete
Manfred Spraul <[EMAIL PROTECTED]> 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
Tom Lane wrote:
Wait a minute. I am *not* buying into any proposal that we need to
support ENABLE_THREAD_SAFETY on machines where libc is not thread-safe.
We have other things to do than adopt an open-ended commitment to work
around threading bugs on obsolete platforms. I don't believe that any
Manfred Spraul <[EMAIL PROTECTED]> writes:
> + * Used to set callback that prevents concurrent access to
> + * non-thread safe functions that libpq needs.
> + * The default implementation uses a libpq internal mutex.
> + * Only required for multithreaded apps on platforms that
> + * do no
Tom Lane wrote:
Personally I find diff -u format completely unreadable :-(. Send
"diff -c" if you want useful commentary.
diff -c is attached. I've removed the signal changes, they are
unrelated. I'll resent them separately.
--
Manfred
Index: src/interfaces/libpq/libpq-fe.h
==
Manfred Spraul <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Wouldn't help anyway, if some other part of the app also calls kerberos.
>>
> That's why I've proposed to use the system from openssl: The libpq user
> must implement a lock callback, and libpq calls it around the critical
> section
Tom Lane wrote:
Manfred Spraul <[EMAIL PROTECTED]> writes:
But what about kerberos: I'm a bit reluctant to add a forth mutex: what
if kerberos calls gethostbyname or getpwuid internally?
Wouldn't help anyway, if some other part of the app also calls kerberos.
That's why I've proposed to
Manfred Spraul <[EMAIL PROTECTED]> writes:
> But what about kerberos: I'm a bit reluctant to add a forth mutex: what
> if kerberos calls gethostbyname or getpwuid internally?
Wouldn't help anyway, if some other part of the app also calls kerberos.
I think we should just state that kerberos isn't
libpq needs additional changes for complete thread safety:
- openssl needs different initialization.
- kerberos is not thread safe.
- functions such as gethostbyname are not thread safe, and could be used
by kerberos. Right now protected with a libpq specific mutex.
- dito for getpwuid and stderr
Manfred Spraul wrote:
> Hi,
>
> I've searched through libpq and looked for global or static variables as
> indicators of non-threadsafe code. I found:
> - Win32 and BeOS: there is a global "ioctlsocket_ret variable, but it
> seems to be a dummy variable that is always discarded.
Right, and it i
Hi,
I've searched through libpq and looked for global or static variables as
indicators of non-threadsafe code. I found:
- Win32 and BeOS: there is a global "ioctlsocket_ret variable, but it
seems to be a dummy variable that is always discarded.
- pg_krb4_init(): Are the kerberos libraries threa
22 matches
Mail list logo
