Re: thread safety tests

Jan Wieck wrote:
> > 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.
>
> 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.

OK, I have added a configure option --enable-thread-safety-force that
compiles with thread safety even if the OS tests fail. I have not
mentioned this in the SGML docs but mention the option in configure
--help and when you get a thread test failure with
--enable-thread-safety.

Patch attached and applied.

> And just to make your day, your tests for thread safety are incomplete.
> 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?

We have libpq locking for kerberos in CVS.

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