Thread: Thread-safe configuration option appears to misfunction
Is it intended that libpq is always compiled with the so-called "thread-safe" compiler option, regardless of whether I used --enable-thread-thing? -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut wrote: > Is it intended that libpq is always compiled with the so-called > "thread-safe" compiler option, regardless of whether I used > --enable-thread-thing? It certainly should not be doing that, but my OS has no thread flags, so I am not seeing it here. What exactly do you see? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian writes: > Peter Eisentraut wrote: > > Is it intended that libpq is always compiled with the so-called > > "thread-safe" compiler option, regardless of whether I used > > --enable-thread-thing? > > It certainly should not be doing that, but my OS has no thread flags, so > I am not seeing it here. What exactly do you see? It's using -D_REENTRANT etc. (linux template) when compiling libpq. -- Peter Eisentraut peter_e@gmx.net
--On Monday, August 04, 2003 17:54:41 +0200 Peter Eisentraut <peter_e@gmx.net> wrote: > Bruce Momjian writes: > >> Peter Eisentraut wrote: >> > Is it intended that libpq is always compiled with the so-called >> > "thread-safe" compiler option, regardless of whether I used >> > --enable-thread-thing? >> >> It certainly should not be doing that, but my OS has no thread flags, so >> I am not seeing it here. What exactly do you see? > > It's using -D_REENTRANT etc. (linux template) when compiling libpq. I think we WANT to do that for libpq so it can be used in a threaded app, since there is no libc_r on Linux to the best of my knowledge. I intend that to happen on UnixWare as well. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
We decided to make separate thread/nonthread libraries if the threading requires any special flags --- we haven't done that yet, and only configure controls it. --------------------------------------------------------------------------- Larry Rosenman wrote: > > > --On Monday, August 04, 2003 17:54:41 +0200 Peter Eisentraut > <peter_e@gmx.net> wrote: > > > Bruce Momjian writes: > > > >> Peter Eisentraut wrote: > >> > Is it intended that libpq is always compiled with the so-called > >> > "thread-safe" compiler option, regardless of whether I used > >> > --enable-thread-thing? > >> > >> It certainly should not be doing that, but my OS has no thread flags, so > >> I am not seeing it here. What exactly do you see? > > > > It's using -D_REENTRANT etc. (linux template) when compiling libpq. > I think we WANT to do that for libpq so it can be used in a threaded app, > since there > is no libc_r on Linux to the best of my knowledge. > > I intend that to happen on UnixWare as well. > > LER > > > > -- > Larry Rosenman http://www.lerctr.org/~ler > Phone: +1 972-414-9812 E-Mail: ler@lerctr.org > US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 > > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
--On Monday, August 04, 2003 12:30:32 -0400 Bruce Momjian <pgman@candle.pha.pa.us> wrote: > > We decided to make separate thread/nonthread libraries if the threading > requires any special flags --- we haven't done that yet, and only > configure controls it. That will be a POLA (principle of least astonishment) violation on UnixWare. LER > > ------------------------------------------------------------------------- > -- > > Larry Rosenman wrote: >> >> >> --On Monday, August 04, 2003 17:54:41 +0200 Peter Eisentraut >> <peter_e@gmx.net> wrote: >> >> > Bruce Momjian writes: >> > >> >> Peter Eisentraut wrote: >> >> > Is it intended that libpq is always compiled with the so-called >> >> > "thread-safe" compiler option, regardless of whether I used >> >> > --enable-thread-thing? >> >> >> >> It certainly should not be doing that, but my OS has no thread flags, >> >> so I am not seeing it here. What exactly do you see? >> > >> > It's using -D_REENTRANT etc. (linux template) when compiling libpq. >> I think we WANT to do that for libpq so it can be used in a threaded >> app, since there >> is no libc_r on Linux to the best of my knowledge. >> >> I intend that to happen on UnixWare as well. >> >> LER >> >> >> >> -- >> Larry Rosenman http://www.lerctr.org/~ler >> Phone: +1 972-414-9812 E-Mail: ler@lerctr.org >> US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 >> -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Larry Rosenman wrote: > > > --On Monday, August 04, 2003 12:30:32 -0400 Bruce Momjian > <pgman@candle.pha.pa.us> wrote: > > > > > We decided to make separate thread/nonthread libraries if the threading > > requires any special flags --- we haven't done that yet, and only > > configure controls it. > That will be a POLA (principle of least astonishment) violation on UnixWare. When we have the capability to do dual library builds, we might have a way to specify a threading flag that will apply to the main libpq and not create a libpq_r. If it is a good flag, can we use it in the template file for all compiling? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
OK, I fixed a number of problems in configure with threads --- please give it a try now. Thanks. --------------------------------------------------------------------------- Peter Eisentraut wrote: > Bruce Momjian writes: > > > Peter Eisentraut wrote: > > > Is it intended that libpq is always compiled with the so-called > > > "thread-safe" compiler option, regardless of whether I used > > > --enable-thread-thing? > > > > It certainly should not be doing that, but my OS has no thread flags, so > > I am not seeing it here. What exactly do you see? > > It's using -D_REENTRANT etc. (linux template) when compiling libpq. > > -- > Peter Eisentraut peter_e@gmx.net > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
--On Monday, August 04, 2003 12:50:31 -0400 Bruce Momjian <pgman@candle.pha.pa.us> wrote: > Larry Rosenman wrote: >> >> >> --On Monday, August 04, 2003 12:30:32 -0400 Bruce Momjian >> <pgman@candle.pha.pa.us> wrote: >> >> > >> > We decided to make separate thread/nonthread libraries if the threading >> > requires any special flags --- we haven't done that yet, and only >> > configure controls it. >> That will be a POLA (principle of least astonishment) violation on >> UnixWare. > > When we have the capability to do dual library builds, we might have a > way to specify a threading flag that will apply to the main libpq and > not create a libpq_r. If it is a good flag, can we use it in the > template file for all compiling? I **THINK** so. What I'm thinking of is -D_REENTRANT for UnixWare especially for libpq. the --with-threads would cause ecpg to be compiled/linked as -lpthread in addition to -D_REENTRANT LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Larry Rosenman wrote: > >> > We decided to make separate thread/nonthread libraries if the threading > >> > requires any special flags --- we haven't done that yet, and only > >> > configure controls it. > >> That will be a POLA (principle of least astonishment) violation on > >> UnixWare. > > > > When we have the capability to do dual library builds, we might have a > > way to specify a threading flag that will apply to the main libpq and > > not create a libpq_r. If it is a good flag, can we use it in the > > template file for all compiling? > I **THINK** so. What I'm thinking of is -D_REENTRANT for UnixWare > especially for libpq. > > the --with-threads would cause ecpg to be compiled/linked as -lpthread in > addition to > -D_REENTRANT Nope, we are not going to link with -lpthread unless it is enabled in configure. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
--On Monday, August 04, 2003 13:11:45 -0400 Bruce Momjian <pgman@candle.pha.pa.us> wrote: > Larry Rosenman wrote: >> >> > We decided to make separate thread/nonthread libraries if the >> >> > threading requires any special flags --- we haven't done that yet, >> >> > and only configure controls it. >> >> That will be a POLA (principle of least astonishment) violation on >> >> UnixWare. >> > >> > When we have the capability to do dual library builds, we might have a >> > way to specify a threading flag that will apply to the main libpq and >> > not create a libpq_r. If it is a good flag, can we use it in the >> > template file for all compiling? >> I **THINK** so. What I'm thinking of is -D_REENTRANT for UnixWare >> especially for libpq. >> >> the --with-threads would cause ecpg to be compiled/linked as -lpthread >> in addition to >> -D_REENTRANT > > Nope, we are not going to link with -lpthread unless it is enabled in > configure. Right. but libpq should be built with -D_REENTRANT on UnixWare regardless of the --with-threads. Read what I said above. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Larry Rosenman wrote: > > > --On Monday, August 04, 2003 13:11:45 -0400 Bruce Momjian > <pgman@candle.pha.pa.us> wrote: > > > Larry Rosenman wrote: > >> >> > We decided to make separate thread/nonthread libraries if the > >> >> > threading requires any special flags --- we haven't done that yet, > >> >> > and only configure controls it. > >> >> That will be a POLA (principle of least astonishment) violation on > >> >> UnixWare. > >> > > >> > When we have the capability to do dual library builds, we might have a > >> > way to specify a threading flag that will apply to the main libpq and > >> > not create a libpq_r. If it is a good flag, can we use it in the > >> > template file for all compiling? > >> I **THINK** so. What I'm thinking of is -D_REENTRANT for UnixWare > >> especially for libpq. > >> > >> the --with-threads would cause ecpg to be compiled/linked as -lpthread > >> in addition to > >> -D_REENTRANT > > > > Nope, we are not going to link with -lpthread unless it is enabled in > > configure. > Right. but libpq should be built with -D_REENTRANT on UnixWare regardless > of the > --with-threads. Well, let's see what additional functionality we need. I am not feeling too friendly on SCO/Unixware right now to jump through hoops. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
--On Monday, August 04, 2003 13:19:57 -0400 Bruce Momjian <pgman@candle.pha.pa.us> wrote: > Larry Rosenman wrote: >> >> >> --On Monday, August 04, 2003 13:11:45 -0400 Bruce Momjian >> <pgman@candle.pha.pa.us> wrote: >> >> > Larry Rosenman wrote: >> >> >> > We decided to make separate thread/nonthread libraries if the >> >> >> > threading requires any special flags --- we haven't done that >> >> >> > yet, and only configure controls it. >> >> >> That will be a POLA (principle of least astonishment) violation on >> >> >> UnixWare. >> >> > >> >> > When we have the capability to do dual library builds, we might >> >> > have a way to specify a threading flag that will apply to the main >> >> > libpq and not create a libpq_r. If it is a good flag, can we use >> >> > it in the template file for all compiling? >> >> I **THINK** so. What I'm thinking of is -D_REENTRANT for UnixWare >> >> especially for libpq. >> >> >> >> the --with-threads would cause ecpg to be compiled/linked as -lpthread >> >> in addition to >> >> -D_REENTRANT >> > >> > Nope, we are not going to link with -lpthread unless it is enabled in >> > configure. >> Right. but libpq should be built with -D_REENTRANT on UnixWare >> regardless of the >> --with-threads. > > Well, let's see what additional functionality we need. I am not > feeling too friendly on SCO/Unixware right now to jump through hoops. Let's not go there. I'm not involved in the IP fight, but I am a USER on that platform, and SCO is thinking ****SERIOUSLY**** about shipping PG on the Platform as part of their extensions offering. What the fr*** harm is it in passing -D_REENTRANT into the libpq build on UnixWare irregardless of the --with-threads* flag? Same argument for allowing the PORT to determine whether to allow/permit the full pathname in for DT_SONAME. Let's not run people off because of what the damn lawyers are doing. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Larry Rosenman <ler@lerctr.org> writes:
> SCO is thinking ****SERIOUSLY**** about shipping PG on the Platform as
> part of their extensions offering.
Why, how nice of them. I don't intend to lift a finger to help.
regards, tom lane
--On Monday, August 04, 2003 14:06:34 -0400 Tom Lane <tgl@sss.pgh.pa.us> wrote: > Larry Rosenman <ler@lerctr.org> writes: >> SCO is thinking ****SERIOUSLY**** about shipping PG on the Platform as >> part of their extensions offering. > > Why, how nice of them. I don't intend to lift a finger to help. Grr. I guess I'll get off the lists now. > > regards, tom lane -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
On Mon, 4 Aug 2003, Tom Lane wrote: > Larry Rosenman <ler@lerctr.org> writes: > > SCO is thinking ****SERIOUSLY**** about shipping PG on the Platform as > > part of their extensions offering. > > Why, how nice of them. I don't intend to lift a finger to help. I don't know, I can think of ONE finger I'd be willing to lift. But not to help really. :-)
Would you send over a modified template/unixware and template/sco to at least allow threading when enabled --- see linux or freebsd for examples --- that is how we are enabling threading. Are you saying you want that flag without --enable-thread-safety? --------------------------------------------------------------------------- Larry Rosenman wrote: > > > --On Monday, August 04, 2003 13:19:57 -0400 Bruce Momjian > <pgman@candle.pha.pa.us> wrote: > > > Larry Rosenman wrote: > >> > >> > >> --On Monday, August 04, 2003 13:11:45 -0400 Bruce Momjian > >> <pgman@candle.pha.pa.us> wrote: > >> > >> > Larry Rosenman wrote: > >> >> >> > We decided to make separate thread/nonthread libraries if the > >> >> >> > threading requires any special flags --- we haven't done that > >> >> >> > yet, and only configure controls it. > >> >> >> That will be a POLA (principle of least astonishment) violation on > >> >> >> UnixWare. > >> >> > > >> >> > When we have the capability to do dual library builds, we might > >> >> > have a way to specify a threading flag that will apply to the main > >> >> > libpq and not create a libpq_r. If it is a good flag, can we use > >> >> > it in the template file for all compiling? > >> >> I **THINK** so. What I'm thinking of is -D_REENTRANT for UnixWare > >> >> especially for libpq. > >> >> > >> >> the --with-threads would cause ecpg to be compiled/linked as -lpthread > >> >> in addition to > >> >> -D_REENTRANT > >> > > >> > Nope, we are not going to link with -lpthread unless it is enabled in > >> > configure. > >> Right. but libpq should be built with -D_REENTRANT on UnixWare > >> regardless of the > >> --with-threads. > > > > Well, let's see what additional functionality we need. I am not > > feeling too friendly on SCO/Unixware right now to jump through hoops. > Let's not go there. I'm not involved in the IP fight, but I am a USER on > that > platform, and SCO is thinking ****SERIOUSLY**** about shipping PG on the > Platform > as part of their extensions offering. > > What the fr*** harm is it in passing -D_REENTRANT into the libpq build on > UnixWare > irregardless of the --with-threads* flag? > > Same argument for allowing the PORT to determine whether to allow/permit > the full > pathname in for DT_SONAME. > > Let's not run people off because of what the damn lawyers are doing. > > LER > > > > > -- > Larry Rosenman http://www.lerctr.org/~ler > Phone: +1 972-414-9812 E-Mail: ler@lerctr.org > US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 > > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
> Let's not go there. I'm not involved in the IP fight, but I am a USER on > that > platform, and SCO is thinking ****SERIOUSLY**** about shipping PG on the > Platform > as part of their extensions offering. > > What the fr*** harm is it in passing -D_REENTRANT into the libpq build on > UnixWare > irregardless of the --with-threads* flag? > > Same argument for allowing the PORT to determine whether to allow/permit > the full > pathname in for DT_SONAME. We did have a discussion on whether we should enable threading by default, and the issue was that we don't even have enough platforms supported at this point, so by running configure with the thread flag, you are asking us to generate a threaded libpq and ecpg, and we will fail if we can't. On BSD/OS, that flag does nothing (the binaries are the same), but we have the flag so people can know if their libs are thread-safe. I think the template files are the way to go at this point. If we support threads on all/most of our platforms, we can think about doing something by default. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
As soon as a beta tarball shows up, I'll cut changes for UnixWare for --enable-threads, and also to do -D_REENTRANT anyway on UnixWare. What about Kean's change to allow absolute DT_SONAME's? Can that get applied, and used for SCO and UnixWare? LER --On Monday, August 04, 2003 18:16:02 -0400 Bruce Momjian <pgman@candle.pha.pa.us> wrote: >> Let's not go there. I'm not involved in the IP fight, but I am a USER >> on that >> platform, and SCO is thinking ****SERIOUSLY**** about shipping PG on the >> Platform >> as part of their extensions offering. >> >> What the fr*** harm is it in passing -D_REENTRANT into the libpq build >> on UnixWare >> irregardless of the --with-threads* flag? >> >> Same argument for allowing the PORT to determine whether to allow/permit >> the full >> pathname in for DT_SONAME. > > We did have a discussion on whether we should enable threading by > default, and the issue was that we don't even have enough platforms > supported at this point, so by running configure with the thread flag, > you are asking us to generate a threaded libpq and ecpg, and we will > fail if we can't. > > On BSD/OS, that flag does nothing (the binaries are the same), but we > have the flag so people can know if their libs are thread-safe. I think > the template files are the way to go at this point. If we support > threads on all/most of our platforms, we can think about doing something > by default. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Larry Rosenman wrote: > As soon as a beta tarball shows up, I'll cut changes for UnixWare for > --enable-threads, > and also to do -D_REENTRANT anyway on UnixWare. OK. > What about Kean's change to allow absolute DT_SONAME's? > > Can that get applied, and used for SCO and UnixWare? Can you verify if it needed only because they honor LD_LIBRARY_PATH on suid executables? If so, I would like to have something that is only in the template file and Makefile.shlib. I think that is possible. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
--On Monday, August 04, 2003 23:01:32 -0400 Bruce Momjian <pgman@candle.pha.pa.us> wrote: > Larry Rosenman wrote: >> As soon as a beta tarball shows up, I'll cut changes for UnixWare for >> --enable-threads, >> and also to do -D_REENTRANT anyway on UnixWare. > > OK. > >> What about Kean's change to allow absolute DT_SONAME's? >> >> Can that get applied, and used for SCO and UnixWare? > > Can you verify if it needed only because they honor LD_LIBRARY_PATH on > suid executables? If so, I would like to have something that is only > in the template file and Makefile.shlib. I think that is possible. and since there is no ld.so.conf/ldconfig type caching at all. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Larry Rosenman writes:> What the fr*** harm is it in passing -D_REENTRANT into the libpq build on > UnixWare> irregardlessof the --with-threads* flag? Indeed for every other sane system out there. Folk are messing around with the thread stuff using here-say as knowledge. We want to compile with _REENTRANT, always! Anything needed in ADDITON to _REENTRANT (i.e thread link flags for libecpg) can be discovered by configure and applied to the build. Even for the rest of PostgreSQL, it will work A-OK if we are already sticking to the rules (i.e. including <errno.h> when using errno). L.
We don't know the ramifications of doing that flag in the backend code, and we don't know the performance problems of doing it in client libraries. First get your own platforms enabled for the existing thread flag, and we can revisit this when most/all our platforms are supported. We want to avoid confusion of having things work for some platforms and not others with no way to communicate that to the users. --------------------------------------------------------------------------- Lee Kindness wrote: > Larry Rosenman writes: > > What the fr*** harm is it in passing -D_REENTRANT into the libpq build on > > UnixWare > > irregardless of the --with-threads* flag? > > Indeed for every other sane system out there. Folk are messing around > with the thread stuff using here-say as knowledge. We want to compile > with _REENTRANT, always! Anything needed in ADDITON to _REENTRANT (i.e > thread link flags for libecpg) can be discovered by configure and > applied to the build. Even for the rest of PostgreSQL, it will work > A-OK if we are already sticking to the rules (i.e. including <errno.h> > when using errno). > > L. > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian writes: > First get your own platforms enabled for the existing thread flag, and > we can revisit this when most/all our platforms are supported. We want > to avoid confusion of having things work for some platforms and not > others with no way to communicate that to the users. Yes, let's settle on that for now (= release 7.4): Without --enable-thread-safety, you get the same old; with --enable-thread-safety, you get _REENTRANT (or equivalent) for libpq and libecpg, and you get pthreads in libecpg. Then users and packagers can judge the impact on their platform for themselves. While the release is out there, we can gather more data on this and information for the forgotten platforms, and then for 7.5 we might have something that pleases more people by default. Where I see this going, however, is three buckets: one group of platforms will have near zero impact and there will be pressure to enable thread safety by default (BSD/OS, Linux, UnixWare), a second group of platforms where there will be an endless debate about which is right (FreeBSD, AIX), and a third group of platforms that have no thread-safety no matter how hard you look (mostly the old ones). So in the end we will either have to document "libpq is thread-safe on platform A, B, and C", or we will have to keep the switch for all platforms and leave it off by default. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut wrote: > Bruce Momjian writes: > > > First get your own platforms enabled for the existing thread flag, and > > we can revisit this when most/all our platforms are supported. We want > > to avoid confusion of having things work for some platforms and not > > others with no way to communicate that to the users. > > Yes, let's settle on that for now (= release 7.4): Without > --enable-thread-safety, you get the same old; with --enable-thread-safety, > you get _REENTRANT (or equivalent) for libpq and libecpg, and you get > pthreads in libecpg. Then users and packagers can judge the impact on > their platform for themselves. While the release is out there, we can > gather more data on this and information for the forgotten platforms, and > then for 7.5 we might have something that pleases more people by default. OK. > Where I see this going, however, is three buckets: one group of platforms > will have near zero impact and there will be pressure to enable thread > safety by default (BSD/OS, Linux, UnixWare), a second group of platforms > where there will be an endless debate about which is right (FreeBSD, AIX), > and a third group of platforms that have no thread-safety no matter how > hard you look (mostly the old ones). So in the end we will either have to > document "libpq is thread-safe on platform A, B, and C", or we will have > to keep the switch for all platforms and leave it off by default. I am hoping groups 1 and 2 can be merged. I think a good rule is that if libc is threadsafe, we can someday enable libpq to be thread-safe by default, and if there is a libc_r that is thread-safe, we create a libpq_r for that. In fact, I thought we were going to try that for 7.4 when --enable-thread-safety is added to configure. Perhaps by 7.5 we can enable the above logic by default. However, I do think we will have to mention the platforms that aren't thread-safe some day, of course, once we enable thread-safe by default. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073