Re: libpq not reentrant

Tom,

I originally worked with Federico to get the garbled passwords issue
resolved which hit us (we use Psycopg, and Zope at work).

Federico's suggestion to use the crypt from libssl is incomplete,
and slightly wrong. The replacement function to use is des_fcrypt()
and it takes an additional argument, a pointer to a buffer to store
the crypted password in. This makes it threadsafe. The OpenSSL
des_fcrypt() should be portable and available on all platforms where
OpenSSL is supported.

Since you already check for OpenSSL elsewhere, I would
vote for that to go into 7.2, but not having contributed to PostgreSQL
earlier I am not even in the position to articulate wishes :)

HOWEVER,

if you change the documentation about libpq regarding to thread-safeness,
you might put a big warning in there that it may not be that thread-safe at
all. A short grep through libpq shows the usage of
gethostbyname(), strerror(), getpwuid() and strtok(), which according to
glibc info pages are NOT thread-safe either, and probably should be worked
around using the _r versions on linux/glibc and verified on the other
platforms.

Preferably, this should be fixed before 7.2 - but thats not my call.

Note: I personally do not like threads. I am not knowledgeable in the area.
My first threaded program I wrote last week, it was for debugging libpq as
we had those problems. This check of libpq is based uppon grepping libc
info pages for _r functions, and then grepping for the hits in libpq, in
other words its more crystall ball gazing than knowledgeable debugging.

YMMV.

Have a nice weekend,

Mario

--
Mario Lorenz Internet: <ml(at)vdazone(dot)org>
Ham Radio: DL5MLO(at)OK0PKL(dot)#BOH(dot)CZE(dot)EU
* This virus needs Windows95 to run!