Thread-safe configuration option appears to misfunction

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, Pennsylvania 19073

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, Pennsylvania 19073

--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, Pennsylvania 19073

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, Pennsylvania 19073

--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, Pennsylvania 19073

--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, Pennsylvania 19073

--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, Pennsylvania 19073

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, Pennsylvania 19073

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, Pennsylvania 19073

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

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, Pennsylvania 19073

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, Pennsylvania 19073

-----Original Message-----
From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
Sent: Wednesday, August 06, 2003 4:29 PM
To: Peter Eisentraut
Cc: Lee Kindness; Larry Rosenman; PostgreSQL Development
Subject: Re: [HACKERS] Thread-safe configuration option appears to

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.

Perhaps a portable BSD licensed threading library could be included for
platforms that do not have a safe thread interface.

Is there a known list of functions with reentrancy problems?

Dann Corbit wrote:

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.

Perhaps a portable BSD licensed threading library could be included for
platforms that do not have a safe thread interface.

Is there a known list of functions with reentrancy problems?

That seems pretty heavy. I think we could support a 3rd party thread
interface if someone wanted to write one, or perhaps it would just work
out of the box, and we could test for its existance via 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, Pennsylvania 19073

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Dann Corbit wrote:

Perhaps a portable BSD licensed threading library could be included for
platforms that do not have a safe thread interface.

That seems pretty heavy.

It seems highly unlikely that you could band-aid threading over a libc
that wasn't thread safe. In any case, it's not our problem. People
running on such a platform are certainly not going to care whether libpq
is thread-safe or not.

regards, tom lane

On Thu, 7 Aug 2003 09:49 am, Tom Lane wrote:

People
running on such a platform are certainly not going to care whether libpq
is thread-safe or not.

Precisely. If your application on that platform can't start multiple threads
of execution, it's a moot point whether the DB interface on that platform is
thread-safe. It'll never get multiple threads running through it anyway.

Regards, Philip Yarra.