Re: thread safety tests

Jan Wieck wrote:
> On 6/9/2004 11:45 AM, Bruce Momjian wrote:
>
> > Jan Wieck wrote:
> >> The problem is that if your thread-safety tests fail, there is no way to
> >> build libpq with -pthread and -DREENTRANT or whatever is required on
> >> that platform. On Solaris this results in errno being defined as
> >>
> >> extern int errno;
> >>
> >> as supposed to
> >>
> >> #define errno *(errno())
> >>
> >> which makes libpq on Solaris completely useless for every program that
> >> uses threads for "something". There is still value in compiling it with
> >> thread support compiler flags, even if it will not result in a thread
> >> safe libpq.
> >
> > Well, first we should find out how to get the thread test to pass for
> > that patform, but for cases where we can't (FreeBSD doesn't have
> > getpwuid_r(), we are stuck. (That might be your Solaris problem as
> > well.)
>
> There is no problem with thread safety on Solaris. The configure script
> for 7.4.2 is broken for it, leading to a broken libpq when using
> --enable-thread-safey.

Oh, yes, to be fixed in 7.4.3.

> > I looked over the code and the only place getpwuid_r (through
> > pqGetpwuid) is used is in libpq to look up the default username based on
> > the euid for the connection to the backend. Unfortunately, I can't find
> > any other way to do such a lookup in a thread-safe manner unless we do a
> > system() or lock/read /etc/passwd ourselves, both of which are ugly.
> >
> > I can't imagine how some OS's cannot give us a thread-safe way to do
> > this.
> >
> > When FreeBSD can't enable threads in 7.5, folks are going to be upset.
> > In 7.4 we allowed it by having our own C code lock/copy the passwd
> > structure, but someone pointed out that calls to getpwuid() in other
> > places in the client code don't have such locking, so it would not work,
> > so it was removed for 7.5.
>
> I disagree that all or nothing is a good strategy. What you have changed
> this to is to deny using PostgreSQL from multithreaded applications on
> platforms that have no getpwuid_r() altogether, if their platform
> happens to require any thread special compiler options for libpq to work
> in general.

Yes, this was the agreed approach. It wasn't all my idea.

> Take Slony as an example. It is multithreaded, and we aren't happy that
> we have to guard the pg_connect() call with a mutex against multiple
> concurrent calls. But since our connections are of long living nature
> this is no problem. And nowhere else in the entire code is any call to
> getpwuid() or anything else. So we have the situation under control. But
> I really don't want to tell people in the build instructions that they
> have to edit libpq's Makefile because PostgreSQL's ./configure script is
> too restrictive.

Yep, a problem. However, when we create libpq we can't know that your
app isn't going to call getpwuid itself, can we; and even if we did, we
couldn't know if other libraries you are calling are using it. I bet
you don't even know that.

> And just to make your day, your tests for thread safety are incomplete.

Why incomplete? Because it doesn't handle kerberos? See below.

> The reason why we use a mutex now on all platforms, thread safe or not,
> is because in the event you have a kerberos lib available (which is not
> thread safe), pg_connect() can crash wether you use kerberos or not. So
> I think when compiling for --enable-thread-safe we should disable
> kerberos in libpq, right?

I thought we added kerberos locking to our current CVS.

As for your general issue, I don't think we want to head down the road
of having a libpq that is safe only if certain qualifications are made
of clients calling it. If folks know enough to deal with those
qualifications, they can use CFLAGS to pass compiler flags to their
libpq build or hack up the code to bypass the thread checks.

What we really need is a way to do the uid->username mapping in a
thread-safe way. Could we check the environment for $USER or $LOGNAME?
Could we require them to be set for thread builds on OS's without
getpwuid_r and in cases where the username is not specified in the
connection string?

If FreeBSD and Solaris both have this issue, it is important for us to
solve it.

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