threads stuff/UnixWare
At the risk of getting my butt kicked again, is there any way we can
talk about how to deal with threads on UnixWare and the libpq stuff?
Has any other platform come up with a need to look for the real pthread_*
calls from libpq?
I would REALLY like us to support threaded programs in UnixWare, and would
like to NOT antagonize the community, but would like to have a direction
I can go to make this happen in 7.5 before we freeze.
Thanks,
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
On Wed, 12 May 2004, Larry Rosenman wrote:
At the risk of getting my butt kicked again, is there any way we can
talk about how to deal with threads on UnixWare and the libpq stuff?Has any other platform come up with a need to look for the real pthread_*
calls from libpq?I would REALLY like us to support threaded programs in UnixWare, and would
like to NOT antagonize the community, but would like to have a direction
I can go to make this happen in 7.5 before we freeze.
Perfect time to start talking about it, at least :)
Do you have a proposed patch to look at for doing this?
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
--On Wednesday, May 12, 2004 12:57:10 -0300 "Marc G. Fournier"
<scrappy@postgresql.org> wrote:
On Wed, 12 May 2004, Larry Rosenman wrote:
At the risk of getting my butt kicked again, is there any way we can
talk about how to deal with threads on UnixWare and the libpq stuff?Has any other platform come up with a need to look for the real pthread_*
calls from libpq?I would REALLY like us to support threaded programs in UnixWare, and
would like to NOT antagonize the community, but would like to have a
direction I can go to make this happen in 7.5 before we freeze.Perfect time to start talking about it, at least :)
Do you have a proposed patch to look at for doing this?
No, as I believe the way I want to do it was frowned upon.
I'd LIKE to be able to have PG wrappers for those functions, and
have the first invocation of them look via dlsym() for the real ones, and
if they are NOT there, use fake functions that assume we are NOT threaded.
If they ARE present, indirect to the real functions.
I am looking for direction before expending a lot of effort on it, if it
will ultimately be rejected.
----
Marc G. Fournier Hub.Org Networking Services
(http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy
ICQ: 7615664
--
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:
At the risk of getting my butt kicked again, is there any way we can
talk about how to deal with threads on UnixWare and the libpq stuff?
In what way does the current thread stuff not work for you?
regards, tom lane
--On Wednesday, May 12, 2004 12:58:58 -0400 Tom Lane <tgl@sss.pgh.pa.us>
wrote:
Larry Rosenman <ler@lerctr.org> writes:
At the risk of getting my butt kicked again, is there any way we can
talk about how to deal with threads on UnixWare and the libpq stuff?In what way does the current thread stuff not work for you?
regards, tom lane
In the initdb compile:
Undefined first referenced
symbol in file
pthread_mutex_unlock libpq.so
pthread_getspecific libpq.so
pthread_mutex_lock libpq.so
pthread_key_create libpq.so
pthread_once libpq.so
pthread_setspecific libpq.so
UX:ld: ERROR: Symbol referencing errors. No output written to initdb
gmake[3]: *** [initdb] Error 1
gmake[3]: Leaving directory `/home/ler/pg-dev/pgsql-server/src/bin/initdb'
gmake[2]: *** [all] Error 2
gmake[2]: Leaving directory `/home/ler/pg-dev/pgsql-server/src/bin'
gmake[1]: *** [all] Error 2
gmake[1]: Leaving directory `/home/ler/pg-dev/pgsql-server/src'
gmake: *** [all] Error 2
$
--
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 Wed, 12 May 2004, Larry Rosenman wrote:
I'd LIKE to be able to have PG wrappers for those functions, and have
the first invocation of them look via dlsym() for the real ones, and if
they are NOT there, use fake functions that assume we are NOT threaded.
Wouldn't it be easier to have a #define?
Correct me if I'm wrong here, but the problem is that we are expecting
thread functinos to be called x_, while Unixware defines them as pthread_,
right? so make Unixware specific #defines that map x_ to pthread_ ...
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
--On Wednesday, May 12, 2004 14:14:30 -0300 "Marc G. Fournier"
<scrappy@postgresql.org> wrote:
On Wed, 12 May 2004, Larry Rosenman wrote:
I'd LIKE to be able to have PG wrappers for those functions, and have
the first invocation of them look via dlsym() for the real ones, and if
they are NOT there, use fake functions that assume we are NOT threaded.Wouldn't it be easier to have a #define?
Correct me if I'm wrong here, but the problem is that we are expecting
thread functinos to be called x_, while Unixware defines them as pthread_,
right? so make Unixware specific #defines that map x_ to pthread_ ...
No, we are expecting them to have pthread_*.
On UnixWare, to get the pthread_* functions, you need to invoke a compiler
option (-Kpthread), to cause libpthread to be linked in.
Since libpq.so now REQUIRES the function, we need to either:
1) force ANY program that uses libpq to be compiled/linked with -Kpthread
or
2) dynamically determine if libpthread is loaded and use the real pthread_*
functions if they are there (libpthread is in the image), or use fake
singlethread versions of the pthread_* calls if libpthread is NOT in the
image.
----
Marc G. Fournier Hub.Org Networking Services
(http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy
ICQ: 7615664
--
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:
--On Wednesday, May 12, 2004 12:58:58 -0400 Tom Lane <tgl@sss.pgh.pa.us>
In what way does the current thread stuff not work for you?
In the initdb compile:
Undefined first referenced
symbol in file
pthread_mutex_unlock libpq.so
pthread_getspecific libpq.so
pthread_mutex_lock libpq.so
pthread_key_create libpq.so
pthread_once libpq.so
pthread_setspecific libpq.so
Hmm. And that means what? Does Unixware not have these functions?
Are we just failing to suck in the needed library?
regards, tom lane
--On Wednesday, May 12, 2004 13:18:35 -0400 Tom Lane <tgl@sss.pgh.pa.us>
wrote:
Larry Rosenman <ler@lerctr.org> writes:
--On Wednesday, May 12, 2004 12:58:58 -0400 Tom Lane <tgl@sss.pgh.pa.us>
In what way does the current thread stuff not work for you?
In the initdb compile:
Undefined first referenced
symbol in file
pthread_mutex_unlock libpq.so
pthread_getspecific libpq.so
pthread_mutex_lock libpq.so
pthread_key_create libpq.so
pthread_once libpq.so
pthread_setspecific libpq.soHmm. And that means what? Does Unixware not have these functions?
Are we just failing to suck in the needed library?regards, tom lane
No, we don't pass the -Kpthread (thread CFLAGS) to the C links.
This is the whole discussion we had back in January/February about forcing
-Kpthread for *ALL* libpq using programs, or dynamically determining
if the image already is linked -Kpthread, or not supporting threads
at all on UW.
#3 is unacceptable to me.
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
On Wed, 12 May 2004, Larry Rosenman wrote:
--On Wednesday, May 12, 2004 14:14:30 -0300 "Marc G. Fournier"
<scrappy@postgresql.org> wrote:On Wed, 12 May 2004, Larry Rosenman wrote:
I'd LIKE to be able to have PG wrappers for those functions, and have
the first invocation of them look via dlsym() for the real ones, and if
they are NOT there, use fake functions that assume we are NOT threaded.Wouldn't it be easier to have a #define?
Correct me if I'm wrong here, but the problem is that we are expecting
thread functinos to be called x_, while Unixware defines them as pthread_,
right? so make Unixware specific #defines that map x_ to pthread_ ...No, we are expecting them to have pthread_*.
On UnixWare, to get the pthread_* functions, you need to invoke a compiler
option (-Kpthread), to cause libpthread to be linked in.Since libpq.so now REQUIRES the function, we need to either:
1) force ANY program that uses libpq to be compiled/linked with -Kpthread
Ummm, shouldn't that be added to the port specific Makefile?
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
--On Wednesday, May 12, 2004 15:02:30 -0300 "Marc G. Fournier"
<scrappy@postgresql.org> wrote:
On Wed, 12 May 2004, Larry Rosenman wrote:
--On Wednesday, May 12, 2004 14:14:30 -0300 "Marc G. Fournier"
<scrappy@postgresql.org> wrote:On Wed, 12 May 2004, Larry Rosenman wrote:
I'd LIKE to be able to have PG wrappers for those functions, and have
the first invocation of them look via dlsym() for the real ones, and
if they are NOT there, use fake functions that assume we are NOT
threaded.Wouldn't it be easier to have a #define?
Correct me if I'm wrong here, but the problem is that we are expecting
thread functinos to be called x_, while Unixware defines them as
pthread_, right? so make Unixware specific #defines that map x_ to
pthread_ ...No, we are expecting them to have pthread_*.
On UnixWare, to get the pthread_* functions, you need to invoke a
compiler option (-Kpthread), to cause libpthread to be linked in.Since libpq.so now REQUIRES the function, we need to either:
1) force ANY program that uses libpq to be compiled/linked with -Kpthread
Ummm, shouldn't that be added to the port specific Makefile?
See my reply to Tom. It forces ALL libpq using programs to be
linked with -Kpthread, which was deemed unacceptable.
----
Marc G. Fournier Hub.Org Networking Services
(http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy
ICQ: 7615664
--
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 Wed, 12 May 2004, Larry Rosenman wrote:
--On Wednesday, May 12, 2004 15:02:30 -0300 "Marc G. Fournier"
<scrappy@postgresql.org> wrote:On Wed, 12 May 2004, Larry Rosenman wrote:
--On Wednesday, May 12, 2004 14:14:30 -0300 "Marc G. Fournier"
<scrappy@postgresql.org> wrote:On Wed, 12 May 2004, Larry Rosenman wrote:
I'd LIKE to be able to have PG wrappers for those functions, and have
the first invocation of them look via dlsym() for the real ones, and
if they are NOT there, use fake functions that assume we are NOT
threaded.Wouldn't it be easier to have a #define?
Correct me if I'm wrong here, but the problem is that we are expecting
thread functinos to be called x_, while Unixware defines them as
pthread_, right? so make Unixware specific #defines that map x_ to
pthread_ ...No, we are expecting them to have pthread_*.
On UnixWare, to get the pthread_* functions, you need to invoke a
compiler option (-Kpthread), to cause libpthread to be linked in.Since libpq.so now REQUIRES the function, we need to either:
1) force ANY program that uses libpq to be compiled/linked with -Kpthread
Ummm, shouldn't that be added to the port specific Makefile?
See my reply to Tom. It forces ALL libpq using programs to be
linked with -Kpthread, which was deemed unacceptable.
deemed unacceptable by whom? Sounds to me alot simpler of a solution then
making wrappers for the pthread_* functions just to accommodate one OS ...
I could see it if this was a wide-spread problem, but it doesn't appear to
be ...
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
--On Wednesday, May 12, 2004 15:39:34 -0300 "Marc G. Fournier"
<scrappy@postgresql.org> wrote:
On Wed, 12 May 2004, Larry Rosenman wrote:
--On Wednesday, May 12, 2004 15:02:30 -0300 "Marc G. Fournier"
<scrappy@postgresql.org> wrote:On Wed, 12 May 2004, Larry Rosenman wrote:
--On Wednesday, May 12, 2004 14:14:30 -0300 "Marc G. Fournier"
<scrappy@postgresql.org> wrote:On Wed, 12 May 2004, Larry Rosenman wrote:
I'd LIKE to be able to have PG wrappers for those functions, and
have the first invocation of them look via dlsym() for the real
ones, and if they are NOT there, use fake functions that assume we
are NOT threaded.Wouldn't it be easier to have a #define?
Correct me if I'm wrong here, but the problem is that we are
expecting thread functinos to be called x_, while Unixware defines
them as pthread_, right? so make Unixware specific #defines that
map x_ to pthread_ ...No, we are expecting them to have pthread_*.
On UnixWare, to get the pthread_* functions, you need to invoke a
compiler option (-Kpthread), to cause libpthread to be linked in.Since libpq.so now REQUIRES the function, we need to either:
1) force ANY program that uses libpq to be compiled/linked with
-KpthreadUmmm, shouldn't that be added to the port specific Makefile?
See my reply to Tom. It forces ALL libpq using programs to be
linked with -Kpthread, which was deemed unacceptable.deemed unacceptable by whom? Sounds to me alot simpler of a solution then
making wrappers for the pthread_* functions just to accommodate one OS ...
I could see it if this was a wide-spread problem, but it doesn't appear to
be ...
Bruce didn't want to muck ip all the .c programs in the distribution to
do that.
As well as any users using libpq.
I'm all ears if the COMMUNITY wants to do it.
LER
----
Marc G. Fournier Hub.Org Networking Services
(http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy
ICQ: 7615664
--
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 Wed, 12 May 2004, Larry Rosenman wrote:
Ummm, shouldn't that be added to the port specific Makefile?
See my reply to Tom. It forces ALL libpq using programs to be
linked with -Kpthread, which was deemed unacceptable.deemed unacceptable by whom? Sounds to me alot simpler of a solution then
making wrappers for the pthread_* functions just to accommodate one OS ...
I could see it if this was a wide-spread problem, but it doesn't appear to
be ...Bruce didn't want to muck ip all the .c programs in the distribution to
do that.
I'm confused now ... what .c programs would have to be mucked up if you
add -Kpthread to the Unixware specific Makefile?
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
--On Wednesday, May 12, 2004 15:59:19 -0300 "Marc G. Fournier"
<scrappy@postgresql.org> wrote:
On Wed, 12 May 2004, Larry Rosenman wrote:
Ummm, shouldn't that be added to the port specific Makefile?
See my reply to Tom. It forces ALL libpq using programs to be
linked with -Kpthread, which was deemed unacceptable.deemed unacceptable by whom? Sounds to me alot simpler of a solution
then making wrappers for the pthread_* functions just to accommodate
one OS ... I could see it if this was a wide-spread problem, but it
doesn't appear to be ...Bruce didn't want to muck ip all the .c programs in the distribution to
do that.I'm confused now ... what .c programs would have to be mucked up if you
add -Kpthread to the Unixware specific Makefile?
initdb, et al.
See these comments in src/template/unixware:
# Disabled because flags are required for all apps using libpq.
# Waiting to see if other platforms need this too. 2004-03-22
THREAD_SUPPORT=yes
# verified UnixWare 7.1.4 2004-03-18
STRERROR_THREADSAFE=yes
GETPWUID_THREADSAFE=yes
GETHOSTBYNAME_THREADSAFE=yes
$
I turned it back on to see if the new stuff had fixed it.
----
Marc G. Fournier Hub.Org Networking Services
(http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy
ICQ: 7615664
--
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:
This is the whole discussion we had back in January/February about forcing
-Kpthread for *ALL* libpq using programs, or dynamically determining
if the image already is linked -Kpthread, or not supporting threads
at all on UW.
Oh, that business :-(. AFAIR we did not much care for any of the
proposed alternatives. Have you thought of any new options?
At this point I'd settle for saying that --enable-thread-safety on
Unixware will generate a library that requires -Kpthread. This is
kinda grungy but it seems that any more-pleasant solution would
require a disproportionate amount of work.
regards, tom lane
--On Wednesday, May 12, 2004 15:39:54 -0400 Tom Lane <tgl@sss.pgh.pa.us>
wrote:
Larry Rosenman <ler@lerctr.org> writes:
This is the whole discussion we had back in January/February about
forcing -Kpthread for *ALL* libpq using programs, or dynamically
determining if the image already is linked -Kpthread, or not supporting
threads at all on UW.Oh, that business :-(. AFAIR we did not much care for any of the
proposed alternatives. Have you thought of any new options?At this point I'd settle for saying that --enable-thread-safety on
Unixware will generate a library that requires -Kpthread. This is
kinda grungy but it seems that any more-pleasant solution would
require a disproportionate amount of work.
If I did the work for the dlsym() stuff would you and the rest of core@
accept it?
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 Wed, 12 May 2004, Larry Rosenman wrote:
--On Wednesday, May 12, 2004 15:59:19 -0300 "Marc G. Fournier"
<scrappy@postgresql.org> wrote:On Wed, 12 May 2004, Larry Rosenman wrote:
Ummm, shouldn't that be added to the port specific Makefile?
See my reply to Tom. It forces ALL libpq using programs to be
linked with -Kpthread, which was deemed unacceptable.deemed unacceptable by whom? Sounds to me alot simpler of a solution
then making wrappers for the pthread_* functions just to accommodate
one OS ... I could see it if this was a wide-spread problem, but it
doesn't appear to be ...Bruce didn't want to muck ip all the .c programs in the distribution to
do that.I'm confused now ... what .c programs would have to be mucked up if you
add -Kpthread to the Unixware specific Makefile?initdb, et al.
See these comments in src/template/unixware:
# Disabled because flags are required for all apps using libpq.
# Waiting to see if other platforms need this too. 2004-03-22
THREAD_SUPPORT=yes
# verified UnixWare 7.1.4 2004-03-18
STRERROR_THREADSAFE=yes
GETPWUID_THREADSAFE=yes
GETHOSTBYNAME_THREADSAFE=yes
$I turned it back on to see if the new stuff had fixed it.
k, I just looked at the template/unixware file myself, and it looks to me
like -Kpthread is already defined, and included as part of THREAD_CPPFLAGS
... is THREAD_CPPFLAGS not honor'd in all of the various Makefile's (ie.
initdb?) ...
Please correct me if I'm wrong here, but so far, the issue seems to be
that now that libpq uses pthread_* by default, Unixware requires -Kpthread
to be used when building all the various support programs that use libpq
... and -Kpthread is defined in template/unixware ... so I'm *really*
confused as to what is actually broken, except maybe the Makefile's
themselves ...
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Larry Rosenman <ler@lerctr.org> writes:
--On Wednesday, May 12, 2004 15:39:54 -0400 Tom Lane <tgl@sss.pgh.pa.us>=20
wrote:At this point I'd settle for saying that --enable-thread-safety on
Unixware will generate a library that requires -Kpthread. This is
kinda grungy but it seems that any more-pleasant solution would
require a disproportionate amount of work.
If I did the work for the dlsym() stuff would you and the rest of core@
accept it?
How invasive a change are we talking about? I'd be inclined to reject a
patch that makes libpq materially less readable ...
regards, tom lane
--On Wednesday, May 12, 2004 16:00:48 -0400 Tom Lane <tgl@sss.pgh.pa.us>
wrote:
Larry Rosenman <ler@lerctr.org> writes:
--On Wednesday, May 12, 2004 15:39:54 -0400 Tom Lane
<tgl@sss.pgh.pa.us>=20 wrote:At this point I'd settle for saying that --enable-thread-safety on
Unixware will generate a library that requires -Kpthread. This is
kinda grungy but it seems that any more-pleasant solution would
require a disproportionate amount of work.If I did the work for the dlsym() stuff would you and the rest of core@
accept it?How invasive a change are we talking about? I'd be inclined to reject a
patch that makes libpq materially less readable ...regards, tom lane
I was thinking of pq_pthread_* calls, and that function would
set a static flag for calling either the real pthread_* function
or a statically named version in libpgport.a that is a single thread
wrapper.
I know, this sucks, but, I don't see any other way, other than linking
*ALL* libpq-using programs (including initdb and friends) with -K pthread.
--
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:
I was thinking of pq_pthread_* calls, and that function would
set a static flag for calling either the real pthread_* function
or a statically named version in libpgport.a that is a single thread
wrapper.
And how will you avoid having a link-time dependency on the real pthread
function? You muttered about dlsym but how much code will that take,
and what kind of runtime penalty will we incur? (IIRC the pthread
functions are performance critical.)
Even more to the point, can you make it work at all? I seem to recall
from the prior discussion that -Kpthread actually changes some code
generation details on that platform. Are -Kpthread and non -Kpthread
libraries interoperable at all?
I know, this sucks, but, I don't see any other way, other than linking
*ALL* libpq-using programs (including initdb and friends) with -K pthread.
-Kpthread doesn't sound that bad to me, as long as it's documented.
regards, tom lane
--On Wednesday, May 12, 2004 16:22:58 -0400 Tom Lane <tgl@sss.pgh.pa.us>
wrote:
Larry Rosenman <ler@lerctr.org> writes:
I was thinking of pq_pthread_* calls, and that function would
set a static flag for calling either the real pthread_* function
or a statically named version in libpgport.a that is a single thread
wrapper.And how will you avoid having a link-time dependency on the real pthread
function? You muttered about dlsym but how much code will that take,
and what kind of runtime penalty will we incur? (IIRC the pthread
functions are performance critical.)
The first call to ANY of the pthread_* functions would set the flag, and
would cache the dlsym() info.
Even more to the point, can you make it work at all? I seem to recall
from the prior discussion that -Kpthread actually changes some code
generation details on that platform. Are -Kpthread and non -Kpthread
libraries interoperable at all?
Yes, this is how libc deals with it.
We wouldn't have a hard symbol for the pthread_* calls.
I can ask the compiler guys at SCO if you want.
I know, this sucks, but, I don't see any other way, other than linking
*ALL* libpq-using programs (including initdb and friends) with -K
pthread.-Kpthread doesn't sound that bad to me, as long as it's documented.
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 Wed, 12 May 2004, Larry Rosenman wrote:
--On Wednesday, May 12, 2004 16:00:48 -0400 Tom Lane <tgl@sss.pgh.pa.us>
wrote:Larry Rosenman <ler@lerctr.org> writes:
--On Wednesday, May 12, 2004 15:39:54 -0400 Tom Lane
<tgl@sss.pgh.pa.us>=20 wrote:At this point I'd settle for saying that --enable-thread-safety on
Unixware will generate a library that requires -Kpthread. This is
kinda grungy but it seems that any more-pleasant solution would
require a disproportionate amount of work.If I did the work for the dlsym() stuff would you and the rest of core@
accept it?How invasive a change are we talking about? I'd be inclined to reject a
patch that makes libpq materially less readable ...regards, tom lane
I was thinking of pq_pthread_* calls, and that function would
set a static flag for calling either the real pthread_* function
or a statically named version in libpgport.a that is a single thread
wrapper.I know, this sucks, but, I don't see any other way, other than linking
*ALL* libpq-using programs (including initdb and friends) with -K pthread.
k, a change that 'sucks', vs linking against -Kpthread ... I'm for the
-Kpthread route myself, which still sounds the 'clean' solution ...
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
--On Wednesday, May 12, 2004 17:29:30 -0300 "Marc G. Fournier"
<scrappy@postgresql.org> wrote:
On Wed, 12 May 2004, Larry Rosenman wrote:
--On Wednesday, May 12, 2004 16:00:48 -0400 Tom Lane <tgl@sss.pgh.pa.us>
wrote:Larry Rosenman <ler@lerctr.org> writes:
--On Wednesday, May 12, 2004 15:39:54 -0400 Tom Lane
<tgl@sss.pgh.pa.us>=20 wrote:At this point I'd settle for saying that --enable-thread-safety on
Unixware will generate a library that requires -Kpthread. This is
kinda grungy but it seems that any more-pleasant solution would
require a disproportionate amount of work.If I did the work for the dlsym() stuff would you and the rest of
core@ accept it?How invasive a change are we talking about? I'd be inclined to reject
a patch that makes libpq materially less readable ...regards, tom lane
I was thinking of pq_pthread_* calls, and that function would
set a static flag for calling either the real pthread_* function
or a statically named version in libpgport.a that is a single thread
wrapper.I know, this sucks, but, I don't see any other way, other than linking
*ALL* libpq-using programs (including initdb and friends) with -K
pthread.k, a change that 'sucks', vs linking against -Kpthread ... I'm for the
-Kpthread route myself, which still sounds the 'clean' solution ...
that was rejected back in Jan-Mar.
BUT, I agree it would work.
I tried to submit the patch, and it was killed.
LER
----
Marc G. Fournier Hub.Org Networking Services
(http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy
ICQ: 7615664
--
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 Wed, 12 May 2004, Larry Rosenman wrote:
k, a change that 'sucks', vs linking against -Kpthread ... I'm for the
-Kpthread route myself, which still sounds the 'clean' solution ...that was rejected back in Jan-Mar.
BUT, I agree it would work.
I tried to submit the patch, and it was killed.
Please re-submit since I don't recall the patch ...
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Larry Rosenman <ler@lerctr.org> writes:
Please save us all time searching by providing a URL ...
I can't find my posts on archives.postgresql.org, but can find it in
MY archives.
Well, then we won't be able to find 'em either, so please repost.
This is heading down the same path I was back on 3/22.
I think at the time we were hoping for a cleaner solution. Since none
has emerged, it would be good of you to refresh our memories of where
things stood.
regards, tom lane
Import Notes
Reply to msg id not found: 468A9F6A7DF6B59D0142D513@lerlaptop.lerctr.org
Tom Lane wrote:
Larry Rosenman <ler@lerctr.org> writes:
Please save us all time searching by providing a URL ...
I can't find my posts on archives.postgresql.org, but can find it in
MY archives.Well, then we won't be able to find 'em either, so please repost.
This is heading down the same path I was back on 3/22.
I think at the time we were hoping for a cleaner solution. Since none
has emerged, it would be good of you to refresh our memories of where
things stood.
[ Sorry I have been away from email today. ]
Larry, now that I have put the thread testing into configure, I am ready
to deal with Unixware. In fact I posted to the list asking you about it
but was too lazy to look up your email address.
Anyway, I think the only solution is going to be to use the -K flag on
all compiles on that platform if you want threads, so anything that uses
libpq will need it. We don't have a client-level flags option at this
point, but we can add it, or just the flag for the backend compile too.
I think that is our best option.
--
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 Wednesday, May 12, 2004 21:08:25 -0400 Bruce Momjian
<pgman@candle.pha.pa.us> wrote:
Tom Lane wrote:
Larry Rosenman <ler@lerctr.org> writes:
Please save us all time searching by providing a URL ...
I can't find my posts on archives.postgresql.org, but can find it in
MY archives.Well, then we won't be able to find 'em either, so please repost.
This is heading down the same path I was back on 3/22.
I think at the time we were hoping for a cleaner solution. Since none
has emerged, it would be good of you to refresh our memories of where
things stood.[ Sorry I have been away from email today. ]
Larry, now that I have put the thread testing into configure, I am ready
to deal with Unixware. In fact I posted to the list asking you about it
but was too lazy to look up your email address.Anyway, I think the only solution is going to be to use the -K flag on
all compiles on that platform if you want threads, so anything that uses
libpq will need it. We don't have a client-level flags option at this
point, but we can add it, or just the flag for the backend compile too.
I think a client-level flag would be best, that way the backend doesn't get
the wrapped functions from libthread.
Can you do the patch?
I think that is our best option.
--
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:
[ Sorry I have been away from email today. ]
Larry, now that I have put the thread testing into configure, I am ready
to deal with Unixware. In fact I posted to the list asking you about it
but was too lazy to look up your email address.Anyway, I think the only solution is going to be to use the -K flag on
all compiles on that platform if you want threads, so anything that uses
libpq will need it. We don't have a client-level flags option at this
point, but we can add it, or just the flag for the backend compile too.I think a client-level flag would be best, that way the backend doesn't get
the wrapped functions from libthread.Can you do the patch?
OK. Can someone think of a clean way to add a flag to everything but
the backend build? Hold, what about /port. Larry, if we compile
anything with threads does everything that links with that object file
require the flag, even if there are no thread flags in the object file?
I don't think so, but I am just checking. Actually, my bet is that it
might do that because if it didn't, there would be no problem with using
that flag on the backend because there are no threading calls in there.
I am afraid of libpgport. Those object files get used by the backend,
and by the client stuff. Larry can -K and non-K object files be mixed
in the same binary?
--
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 Wednesday, May 12, 2004 21:55:40 -0400 Bruce Momjian
<pgman@candle.pha.pa.us> wrote:
Larry Rosenman wrote:
[ Sorry I have been away from email today. ]
Larry, now that I have put the thread testing into configure, I am
ready to deal with Unixware. In fact I posted to the list asking you
about it but was too lazy to look up your email address.Anyway, I think the only solution is going to be to use the -K flag on
all compiles on that platform if you want threads, so anything that
uses libpq will need it. We don't have a client-level flags option at
this point, but we can add it, or just the flag for the backend
compile too.I think a client-level flag would be best, that way the backend doesn't
get the wrapped functions from libthread.Can you do the patch?
OK. Can someone think of a clean way to add a flag to everything but
the backend build? Hold, what about /port. Larry, if we compile
anything with threads does everything that links with that object file
require the flag, even if there are no thread flags in the object file?
I don't think so, but I am just checking. Actually, my bet is that it
might do that because if it didn't, there would be no problem with using
that flag on the backend because there are no threading calls in there.
Yes, there would still be the overhead, because the functions that
libthread wraps would go through that overhead since libthread does it's
magic at _ini time.
Y'all were concerned with overhead in previous discussions.
If you want to link the backend with -Kpthread, you can, but basically the
client code (initdb, et al) should be -Kpthread, and the backend should NOT
since there are no threads calls in the backend.
I am afraid of libpgport. Those object files get used by the backend,
and by the client stuff. Larry can -K and non-K object files be mixed
in the same binary?
Yes, they can.
But, you MUST link ANY pthread_* using code with -K pthread.
See above discussion.
--
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:
Yes, there would still be the overhead, because the functions that
libthread wraps would go through that overhead since libthread does it's
magic at _ini time.Y'all were concerned with overhead in previous discussions.
If you want to link the backend with -Kpthread, you can, but basically the
client code (initdb, et al) should be -Kpthread, and the backend should NOT
since there are no threads calls in the backend.I am afraid of libpgport. Those object files get used by the backend,
and by the client stuff. Larry can -K and non-K object files be mixed
in the same binary?Yes, they can.
But, you MUST link ANY pthread_* using code with -K pthread.
OK, can someone come up with a cute way to add flags only to things that
use libpq, meaning /interfaces and /bin?
--
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 Wednesday, May 12, 2004 22:26:03 -0400 Bruce Momjian
<pgman@candle.pha.pa.us> wrote:
Larry Rosenman wrote:
Yes, there would still be the overhead, because the functions that
libthread wraps would go through that overhead since libthread does it's
magic at _ini time.Y'all were concerned with overhead in previous discussions.
If you want to link the backend with -Kpthread, you can, but basically
the client code (initdb, et al) should be -Kpthread, and the backend
should NOT since there are no threads calls in the backend.I am afraid of libpgport. Those object files get used by the backend,
and by the client stuff. Larry can -K and non-K object files be mixed
in the same binary?Yes, they can.
But, you MUST link ANY pthread_* using code with -K pthread.
OK, can someone come up with a cute way to add flags only to things that
use libpq, meaning /interfaces and /bin?
What about where -lpq is specified?
(I'm NOT a GNU Make guru).
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
I know, this sucks, but, I don't see any other way, other than linking
*ALL* libpq-using programs (including initdb and friends) with -K
pthread.
How about making a libpq.so (without pthread) and a thread safe
libpq_r.so ?
Andreas
Import Notes
Resolved by subject fallback
--On Thursday, May 13, 2004 09:54:02 +0200 Zeugswetter Andreas SB SD
<ZeugswetterA@spardat.at> wrote:
I know, this sucks, but, I don't see any other way, other than linking
*ALL* libpq-using programs (including initdb and friends) with -Kpthread.
How about making a libpq.so (without pthread) and a thread safe
libpq_r.so ?
That's against the way this platform does things. I.E. the only
library is libc. All the other system supplied libs do the right thing
in the presence or absence of libthread in the image.
I did get a note from my SCO contacts that they are looking into how
to make it easier for stuff to be threads ready, but I don't expect
that to be ready for 7.5 release.
The -Kpthread on all libpq using programs is the easiest way FOR NOW.
Thanks,
LER
Andreas
--
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:
I did get a note from my SCO contacts that they are looking into how
to make it easier for stuff to be threads ready, but I don't expect
that to be ready for 7.5 release.
The -Kpthread on all libpq using programs is the easiest way FOR NOW.
Hmm. If there is work happening at the platform level to improve
matters, then I'd definitely vote for taking the simplest solution
(ie -Kpthread everywhere) for now. We can always do all that other
work later if nothing gets fixed; but why invest a lot of work for
what might be only a short-term problem?
regards, tom lane
--On Thursday, May 13, 2004 09:18:21 -0400 Tom Lane <tgl@sss.pgh.pa.us>
wrote:
Larry Rosenman <ler@lerctr.org> writes:
I did get a note from my SCO contacts that they are looking into how
to make it easier for stuff to be threads ready, but I don't expect
that to be ready for 7.5 release.The -Kpthread on all libpq using programs is the easiest way FOR NOW.
Hmm. If there is work happening at the platform level to improve
matters, then I'd definitely vote for taking the simplest solution
(ie -Kpthread everywhere) for now. We can always do all that other
work later if nothing gets fixed; but why invest a lot of work for
what might be only a short-term problem?
I agree. the only issue is how to set up our makefiles to only do the
-Kpthread/-pthreads(gcc) flags on the client code, and not do it for
the backend itself.
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
Larry Rosenman wrote:
-- Start of PGP signed section.
--On Thursday, May 13, 2004 09:18:21 -0400 Tom Lane <tgl@sss.pgh.pa.us>
wrote:Larry Rosenman <ler@lerctr.org> writes:
I did get a note from my SCO contacts that they are looking into how
to make it easier for stuff to be threads ready, but I don't expect
that to be ready for 7.5 release.The -Kpthread on all libpq using programs is the easiest way FOR NOW.
Hmm. If there is work happening at the platform level to improve
matters, then I'd definitely vote for taking the simplest solution
(ie -Kpthread everywhere) for now. We can always do all that other
work later if nothing gets fixed; but why invest a lot of work for
what might be only a short-term problem?[ added blank line here ]
I agree. the only issue is how to set up our makefiles to only do the
-Kpthread/-pthreads(gcc) flags on the client code, and not do it for
the backend itself.
I think mixing a pgport that has thread flags with a backend that does
not is more risky than just compiling everything with the same thread
flags.
--
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 19073Bruce Momjian <pgman@candle.pha.pa.us> writes:
Larry Rosenman wrote:
I agree. the only issue is how to set up our makefiles to only do the
-Kpthread/-pthreads(gcc) flags on the client code, and not do it for
the backend itself.
I think mixing a pgport that has thread flags with a backend that does
not is more risky than just compiling everything with the same thread
flags.
Can we get this straight: is -Kpthread a compile flag or just a link flag?
If the latter then it should not be needed in building the libpgport files.
If the former then adding it to LDFLAGS is the wrong thing.
regards, tom lane
Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Larry Rosenman wrote:
I agree. the only issue is how to set up our makefiles to only do the
-Kpthread/-pthreads(gcc) flags on the client code, and not do it for
the backend itself.I think mixing a pgport that has thread flags with a backend that does
not is more risky than just compiling everything with the same thread
flags.Can we get this straight: is -Kpthread a compile flag or just a link flag?
If the latter then it should not be needed in building the libpgport files.
If the former then adding it to LDFLAGS is the wrong thing.
-Kpthread is needed for both compile and link, and the PTHREAD_CFLAGS is
used for both compile and link phases.
--
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 Thursday, May 13, 2004 10:05:22 -0400 Bruce Momjian
<pgman@candle.pha.pa.us> wrote:
Basically, as things set right now in CVS, Unixware is ready to go
because it thread for everything. We don't have per-template thread
settings anymore because we test all of it in configure.
Was a change made to link initdb et al with -Kpthread? It doesn't seem to
be in AnonCVS yet.
--
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
Import Notes
Reply to msg id not found: 200405131405.i4DE5MH13086@candle.pha.pa.usReference msg id not found: 200405131405.i4DE5MH13086@candle.pha.pa.us | Resolved by subject fallback
Larry Rosenman wrote:
-- Start of PGP signed section.
--On Thursday, May 13, 2004 10:05:22 -0400 Bruce Momjian
<pgman@candle.pha.pa.us> wrote:Basically, as things set right now in CVS, Unixware is ready to go
because it thread for everything. We don't have per-template thread
settings anymore because we test all of it in configure.Was a change made to link initdb et al with -Kpthread? It doesn't seem to
be in AnonCVS yet.
Really? You are configuring with --enable-thread-safety? I just
updated your template in CVS, and it is attached. However, any old CVS
should work fine.
--
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 19073Attachments:
--On Thursday, May 13, 2004 11:44:59 -0400 Bruce Momjian
<pgman@candle.pha.pa.us> wrote:
Larry Rosenman wrote:
-- Start of PGP signed section.--On Thursday, May 13, 2004 10:05:22 -0400 Bruce Momjian
<pgman@candle.pha.pa.us> wrote:Basically, as things set right now in CVS, Unixware is ready to go
because it thread for everything. We don't have per-template thread
settings anymore because we test all of it in configure.Was a change made to link initdb et al with -Kpthread? It doesn't seem
to be in AnonCVS yet.Really? You are configuring with --enable-thread-safety? I just
updated your template in CVS, and it is attached. However, any old CVS
should work fine.
Nope, initdb is where we still die:
cc -O -Kinline initdb.o exec.o -L../../../src/interfaces/libpq -lpq
-L../../../src/port -L/usr/local/lib -Wl,-R/usr/local/pgsql/lib -lz
-lreadline -ltermcap -lresolv -lgen -lld -lsocket -lnsl -ldl -lm -lpgport
-o initdb
Undefined first referenced
symbol in file
pthread_mutex_unlock libpq.so
pthread_getspecific libpq.so
pthread_mutex_lock libpq.so
pthread_key_create libpq.so
pthread_once libpq.so
pthread_setspecific libpq.so
UX:ld: ERROR: Symbol referencing errors. No output written to initdb
gmake[3]: *** [initdb] Error 1
gmake[3]: Leaving directory `/home/ler/pg-dev/pgsql-server/src/bin/initdb'
gmake[2]: *** [all] Error 2
gmake[2]: Leaving directory `/home/ler/pg-dev/pgsql-server/src/bin'
gmake[1]: *** [all] Error 2
gmake[1]: Leaving directory `/home/ler/pg-dev/pgsql-server/src'
gmake: *** [all] Error 2
$
--
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:
Really? You are configuring with --enable-thread-safety? I just
updated your template in CVS, and it is attached. However, any old CVS
should work fine.Nope, initdb is where we still die:
OH! I remember now. What we have to do for this platform only is to
pass the thread flags into all compile/links. I forgot that step.
Let me work on that and send you a patch.
--
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 19073Larry Rosenman wrote:
Really? You are configuring with --enable-thread-safety? I just
updated your template in CVS, and it is attached. However, any old CVS
should work fine.Nope, initdb is where we still die:
Patch applied:
Force thread flags for all Unixware builds if threading is requested.
This is required because once you link with a library that uses threads,
all references to that library have to use thread flags.
--
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 19073Attachments:
/bjm/difftext/plainDownload
Index: src/Makefile.global.in
===================================================================
RCS file: /cvsroot/pgsql-server/src/Makefile.global.in,v
retrieving revision 1.182
diff -c -c -r1.182 Makefile.global.in
*** src/Makefile.global.in 11 May 2004 21:57:14 -0000 1.182
--- src/Makefile.global.in 13 May 2004 23:03:12 -0000
***************
*** 177,182 ****
--- 177,188 ----
CFLAGS += -Wall -Wmissing-prototypes -Wmissing-declarations
endif
+ # Unixware needs threads for everything that uses libpq
+ ifeq ($(PORTNAME),unixware)
+ CFLAGS += "$PTHREAD_CFLAGS"
+ endif
+
+
# Kind-of compilers
YACC = @YACC@
--On Thursday, May 13, 2004 19:06:15 -0400 Bruce Momjian
<pgman@candle.pha.pa.us> wrote:
Larry Rosenman wrote:
Really? You are configuring with --enable-thread-safety? I just
updated your template in CVS, and it is attached. However, any old CVS
should work fine.Nope, initdb is where we still die:
Patch applied:
Force thread flags for all Unixware builds if threading is requested.
This is required because once you link with a library that uses threads,
all references to that library have to use thread flags.
I manually added that patch, and re-did configure, et al from a gmake
maintainer-clean, and we still die at initdb:
cc -O -Kinline initdb.o exec.o -L../../../src/interfaces/libpq -lpq
-L../../../src/port -L/usr/local/lib -Wl,-R/usr/local/pgsql/lib -lz
-lreadline -ltermcap -lresolv -lgen -lld -lsocket -lnsl -ldl -lm -lpgport
-o initdb
Undefined first referenced
symbol in file
pthread_mutex_unlock libpq.so
pthread_getspecific libpq.so
pthread_mutex_lock libpq.so
pthread_key_create libpq.so
pthread_once libpq.so
pthread_setspecific libpq.so
UX:ld: ERROR: Symbol referencing errors. No output written to initdb
gmake[3]: *** [initdb] Error 1
gmake[3]: Leaving directory `/home/ler/pg-dev/pgsql-server/src/bin/initdb'
gmake[2]: *** [all] Error 2
gmake[2]: Leaving directory `/home/ler/pg-dev/pgsql-server/src/bin'
gmake[1]+ Done(2) gmake >gmake.out 2>&1 & $: *** [all] Error 2
gmake[1]+ Done(2) gmake >gmake.out 2>&1 & $: Leaving directory `/home/ler/pg-dev/pgsql-server/src'
gmake: *** [all] Error 2
[1]: + Done(2) gmake >gmake.out 2>&1 & $
$
--
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 <pgman@candle.pha.pa.us> writes:
*** src/Makefile.global.in 11 May 2004 21:57:14 -0000 1.182 --- src/Makefile.global.in 13 May 2004 23:03:12 -0000 *************** *** 177,182 **** --- 177,188 ---- CFLAGS += -Wall -Wmissing-prototypes -Wmissing-declarations endif
+ # Unixware needs threads for everything that uses libpq + ifeq ($(PORTNAME),unixware) + CFLAGS += "$PTHREAD_CFLAGS" + endif + + # Kind-of compilers
YACC = @YACC@
Yech. Isn't this what the Makefile.port files are for? Makefile.global
should never contain any "#ifdef port" junk.
regards, tom lane
\Larry Rosenman wrote:
This is required because once you link with a library that uses threads,
all references to that library have to use thread flags.I manually added that patch, and re-did configure, et al from a gmake
maintainer-clean, and we still die at initdb:cc -O -Kinline initdb.o exec.o -L../../../src/interfaces/libpq -lpq
-L../../../src/port -L/usr/local/lib -Wl,-R/usr/local/pgsql/lib -lz
-lreadline -ltermcap -lresolv -lgen -lld -lsocket -lnsl -ldl -lm -lpgport
-o initdb
OK, we need to see -Kpthread in that compile line. Would you look at
Makefile.global at where I add the thread flags to see why isn't
working.
--
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 Thursday, May 13, 2004 19:46:00 -0400 Tom Lane <tgl@sss.pgh.pa.us>
wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
*** src/Makefile.global.in 11 May 2004 21:57:14 -0000 1.182 --- src/Makefile.global.in 13 May 2004 23:03:12 -0000 *************** *** 177,182 **** --- 177,188 ---- CFLAGS += -Wall -Wmissing-prototypes -Wmissing-declarations endif+ # Unixware needs threads for everything that uses libpq + ifeq ($(PORTNAME),unixware) + CFLAGS += "$PTHREAD_CFLAGS" + endif + + # Kind-of compilersYACC = @YACC@
Yech. Isn't this what the Makefile.port files are for? Makefile.global
should never contain any "#ifdef port" junk.regards, tom lane
It also appears from testing, that this does NOT fix the initdb issue.
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
Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
*** src/Makefile.global.in 11 May 2004 21:57:14 -0000 1.182 --- src/Makefile.global.in 13 May 2004 23:03:12 -0000 *************** *** 177,182 **** --- 177,188 ---- CFLAGS += -Wall -Wmissing-prototypes -Wmissing-declarations endif+ # Unixware needs threads for everything that uses libpq + ifeq ($(PORTNAME),unixware) + CFLAGS += "$PTHREAD_CFLAGS" + endif + + # Kind-of compilersYACC = @YACC@
Yech. Isn't this what the Makefile.port files are for? Makefile.global
should never contain any "#ifdef port" junk.
So we just add the thing in the template file? Yea, I can do that. I
did it there because Win32 already had something for libs. Does the
template file get included in Makefile.global? I didn't think so.
Part of the problem is we don't know if they have asked for threads at
the time we load the template file from configure, no?
--
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 19073Bruce Momjian <pgman@candle.pha.pa.us> writes:
So we just add the thing in the template file? Yea, I can do that. I
did it there because Win32 already had something for libs. Does the
template file get included in Makefile.global? I didn't think so.
Not the template, the port-specific makefile.
regards, tom lane
Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
So we just add the thing in the template file? Yea, I can do that. I
did it there because Win32 already had something for libs. Does the
template file get included in Makefile.global? I didn't think so.Not the template, the port-specific makefile.
Oh, I forgot about those. Done.
--
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 Thursday, May 13, 2004 20:03:24 -0400 Bruce Momjian
<pgman@candle.pha.pa.us> wrote:
Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
So we just add the thing in the template file? Yea, I can do that. I
did it there because Win32 already had something for libs. Does the
template file get included in Makefile.global? I didn't think so.Not the template, the port-specific makefile.
Oh, I forgot about those. Done.
I did this patch, and it works:
$ cvs diff -u Makefile.unixware
Index: Makefile.unixware
===================================================================
RCS file: /projects/cvsroot/pgsql-server/src/makefiles/Makefile.unixware,v
retrieving revision 1.17
diff -u -r1.17 Makefile.unixware
--- Makefile.unixware 5 Jan 2003 13:45:47 -0000 1.17
+++ Makefile.unixware 14 May 2004 00:06:07 -0000
@@ -25,6 +25,7 @@
else
SO_FLAGS = -G
endif
+CFLAGS += $(PTHREAD_CFLAGS) %.so: %.o
$(CC) $(SO_FLAGS) -o $@ $<
$
--
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
Good. I changed my commit to use your version.
---------------------------------------------------------------------------
Larry Rosenman wrote:
-- Start of PGP signed section.
--On Thursday, May 13, 2004 20:03:24 -0400 Bruce Momjian
<pgman@candle.pha.pa.us> wrote:Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
So we just add the thing in the template file? Yea, I can do that. I
did it there because Win32 already had something for libs. Does the
template file get included in Makefile.global? I didn't think so.Not the template, the port-specific makefile.
Oh, I forgot about those. Done.
I did this patch, and it works:
$ cvs diff -u Makefile.unixware Index: Makefile.unixware =================================================================== RCS file: /projects/cvsroot/pgsql-server/src/makefiles/Makefile.unixware,v retrieving revision 1.17 diff -u -r1.17 Makefile.unixware --- Makefile.unixware 5 Jan 2003 13:45:47 -0000 1.17 +++ Makefile.unixware 14 May 2004 00:06:07 -0000 @@ -25,6 +25,7 @@ else SO_FLAGS = -G endif +CFLAGS += $(PTHREAD_CFLAGS)%.so: %.o
$(CC) $(SO_FLAGS) -o $@ $<
$--
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
-- End of PGP section, PGP failed!
--
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 Thursday, May 13, 2004 20:11:45 -0400 Bruce Momjian
<pgman@candle.pha.pa.us> wrote:
Good. I changed my commit to use your version.
Thanks!
Do we care about regression failures at this stage?
I have int4/int8/join failures (join is not new, and is
an order issue).
the int4/int8 have to do with NaN and Infinity i/o.
--
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:
the int4/int8 have to do with NaN and Infinity i/o.
Those we care about. I was hoping CVS tip would Just Work Everywhere
on that point, but evidently not :-(. What do you get? Did it work
better in 7.4? Does Unixware support NaN/Infinity at all?
regards, tom lane
--On Thursday, May 13, 2004 20:49:28 -0400 Tom Lane <tgl@sss.pgh.pa.us>
wrote:
Larry Rosenman <ler@lerctr.org> writes:
the int4/int8 have to do with NaN and Infinity i/o.
Those we care about. I was hoping CVS tip would Just Work Everywhere
on that point, but evidently not :-(. What do you get? Did it work
better in 7.4? Does Unixware support NaN/Infinity at all?regards, tom lane
Yes, we support NaN's and Inf. From the fscanf manpage:
When matching floating numbers, the locale's decimal point character
is taken to introduce a fractional portion, the sequences inf and
infinity (case ignored) are taken to represent infinities, and the
sequence nan[(m)] (case ignored), where the optional parenthesized m
consists of zero or more alphanumeric or underscore (_) characters,
are taken to represent NaNs (not-a-numbers). Note, however, that the
locale's thousands' separator character will not be recognized as
such.
I got:
*** ./expected/float4.out Thu Mar 11 18:25:40 2004
--- ./results/float4.out Thu May 13 19:08:18 2004
***************
*** 33,67 ****
ERROR: invalid input syntax for type real: "123 5"
-- special inputs
SELECT 'NaN'::float4;
! float4
! --------
! NaN
! (1 row)
!
SELECT 'nan'::float4;
! float4
! --------
! NaN
! (1 row)
!
SELECT ' NAN '::float4;
! float4
! --------
! NaN
! (1 row)
!
SELECT 'infinity'::float4;
! float4
! ----------
! Infinity
! (1 row)
!
SELECT ' -INFINiTY '::float4;
! float4
! -----------
! -Infinity
! (1 row)
!
-- bad special inputs
SELECT 'N A N'::float4;
ERROR: invalid input syntax for type real: "N A N"
--- 33,47 ----
ERROR: invalid input syntax for type real: "123 5"
-- special inputs
SELECT 'NaN'::float4;
! ERROR: invalid input syntax for type real: "NaN"
SELECT 'nan'::float4;
! ERROR: invalid input syntax for type real: "nan"
SELECT ' NAN '::float4;
! ERROR: invalid input syntax for type real: " NAN "
SELECT 'infinity'::float4;
! ERROR: invalid input syntax for type real: "infinity"
SELECT ' -INFINiTY '::float4;
! ERROR: invalid input syntax for type real: " -INFINiTY "
-- bad special inputs
SELECT 'N A N'::float4;
ERROR: invalid input syntax for type real: "N A N"
***************
*** 70,88 ****
SELECT ' INFINITY x'::float4;
ERROR: invalid input syntax for type real: " INFINITY x"
SELECT 'Infinity'::float4 + 100.0;
! ERROR: type "double precision" value out of range: overflow
SELECT 'Infinity'::float4 / 'Infinity'::float4;
! ?column?
! ----------
! NaN
! (1 row)
!
SELECT 'nan'::float4 / 'nan'::float4;
! ?column?
! ----------
! NaN
! (1 row)
!
SELECT '' AS five, FLOAT4_TBL.*;
five | f1
------+-------------
--- 50,60 ----
SELECT ' INFINITY x'::float4;
ERROR: invalid input syntax for type real: " INFINITY x"
SELECT 'Infinity'::float4 + 100.0;
! ERROR: invalid input syntax for type real: "Infinity"
SELECT 'Infinity'::float4 / 'Infinity'::float4;
! ERROR: invalid input syntax for type real: "Infinity"
SELECT 'nan'::float4 / 'nan'::float4;
! ERROR: invalid input syntax for type real: "nan"
SELECT '' AS five, FLOAT4_TBL.*;
five | f1
------+-------------======================================================================
*** ./expected/float8.out Fri Apr 23 15:32:20 2004
--- ./results/float8.out Thu May 13 19:08:18 2004
***************
*** 33,67 ****
ERROR: invalid input syntax for type double precision: "123 5"
-- special inputs
SELECT 'NaN'::float8;
! float8
! --------
! NaN
! (1 row)
!
SELECT 'nan'::float8;
! float8
! --------
! NaN
! (1 row)
!
SELECT ' NAN '::float8;
! float8
! --------
! NaN
! (1 row)
!
SELECT 'infinity'::float8;
! float8
! ----------
! Infinity
! (1 row)
!
SELECT ' -INFINiTY '::float8;
! float8
! -----------
! -Infinity
! (1 row)
!
-- bad special inputs
SELECT 'N A N'::float8;
ERROR: invalid input syntax for type double precision: "N A N"
--- 33,47 ----
ERROR: invalid input syntax for type double precision: "123 5"
-- special inputs
SELECT 'NaN'::float8;
! ERROR: invalid input syntax for type double precision: "NaN"
SELECT 'nan'::float8;
! ERROR: invalid input syntax for type double precision: "nan"
SELECT ' NAN '::float8;
! ERROR: invalid input syntax for type double precision: " NAN "
SELECT 'infinity'::float8;
! ERROR: invalid input syntax for type double precision: "infinity"
SELECT ' -INFINiTY '::float8;
! ERROR: invalid input syntax for type double precision: "
-INFINiTY "
-- bad special inputs
SELECT 'N A N'::float8;
ERROR: invalid input syntax for type double precision: "N A N"
***************
*** 70,88 ****
SELECT ' INFINITY x'::float8;
ERROR: invalid input syntax for type double precision: " INFINITY x"
SELECT 'Infinity'::float8 + 100.0;
! ERROR: type "double precision" value out of range: overflow
SELECT 'Infinity'::float8 / 'Infinity'::float8;
! ?column?
! ----------
! NaN
! (1 row)
!
SELECT 'nan'::float8 / 'nan'::float8;
! ?column?
! ----------
! NaN
! (1 row)
!
SELECT '' AS five, FLOAT8_TBL.*;
five | f1
------+----------------------
--- 50,60 ----
SELECT ' INFINITY x'::float8;
ERROR: invalid input syntax for type double precision: " INFINITY x"
SELECT 'Infinity'::float8 + 100.0;
! ERROR: invalid input syntax for type double precision: "Infinity"
SELECT 'Infinity'::float8 / 'Infinity'::float8;
! ERROR: invalid input syntax for type double precision: "Infinity"
SELECT 'nan'::float8 / 'nan'::float8;
! ERROR: invalid input syntax for type double precision: "nan"
SELECT '' AS five, FLOAT8_TBL.*;
five | f1
------+----------------------======================================================================
*** ./expected/join.out Thu Sep 25 01:58:06 2003
--- ./results/join.out Thu May 13 19:08:49 2004
***************
*** 1732,1739 ****
| 6 | 6 | six |
| 7 | 7 | seven |
| 8 | 8 | eight |
- | | | null |
| | 0 | zero |
(13 rows) SELECT '' AS "xxx", *
--- 1732,1739 ----
| 6 | 6 | six |
| 7 | 7 | seven |
| 8 | 8 | eight |
| | 0 | zero |
+ | | | null |
(13 rows) SELECT '' AS "xxx", *
***************
*** 1752,1759 ****
| 6 | 6 | six |
| 7 | 7 | seven |
| 8 | 8 | eight |
- | | | null |
| | 0 | zero |
(13 rows)
SELECT '' AS "xxx", *
--- 1752,1759 ----
| 6 | 6 | six |
| 7 | 7 | seven |
| 8 | 8 | eight |
| | 0 | zero |
+ | | | null |
(13 rows) SELECT '' AS "xxx", *
***************
*** 1793,1800 ****
-----+---+---+-------+----
| 0 | | zero |
| 1 | 4 | one | -1
- | 2 | 3 | two | 2
| 2 | 3 | two | 4
| 3 | 2 | three | -3
| 4 | 1 | four |
| 5 | 0 | five | -5
--- 1793,1800 ----
-----+---+---+-------+----
| 0 | | zero |
| 1 | 4 | one | -1
| 2 | 3 | two | 4
+ | 2 | 3 | two | 2
| 3 | 2 | three | -3
| 4 | 1 | four |
| 5 | 0 | five | -5
***************
*** 1815,1822 ****
-----+---+---+-------+----
| 0 | | zero |
| 1 | 4 | one | -1
- | 2 | 3 | two | 2
| 2 | 3 | two | 4
| 3 | 2 | three | -3
| 4 | 1 | four |
| 5 | 0 | five | -5
--- 1815,1822 ----
-----+---+---+-------+----
| 0 | | zero |
| 1 | 4 | one | -1
| 2 | 3 | two | 4
+ | 2 | 3 | two | 2
| 3 | 2 | three | -3
| 4 | 1 | four |
| 5 | 0 | five | -5======================================================================
7.4.* passed all but join.
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:
Does Unixware support NaN/Infinity at all?
Yes, we support NaN's and Inf.
Hmph. Apparently their strtod() has thought of some original new way to
misbehave on those inputs. Would you mind tracing through float4in() or
float8in() to see exactly how it manages to fail?
regards, tom lane
--On Thursday, May 13, 2004 21:14:40 -0400 Tom Lane <tgl@sss.pgh.pa.us>
wrote:
Larry Rosenman <ler@lerctr.org> writes:
Does Unixware support NaN/Infinity at all?
Yes, we support NaN's and Inf.
Hmph. Apparently their strtod() has thought of some original new way to
misbehave on those inputs. Would you mind tracing through float4in() or
float8in() to see exactly how it manages to fail?regards, tom lane
I ran a quick C test:
cc -O -o test3 test3.c
$ ./test3
num=nan
errno=0
$ cat test3.c
#include <stdlib.h>
#include <stdio.h>
#include <errno.h>
int main(int argc,char **argv)
{
double num;
char *input="NaN";
char **ptr;
num=strtod(input,ptr);
printf("num=%g\n",num);
printf("errno=%ld\n",errno);
exit(0);
}
So, how's the easiest way to trace PG's float4in stuff?
--
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:
I ran a quick C test:
Where does it leave the "ptr" pointing to?
So, how's the easiest way to trace PG's float4in stuff?
gdb is my favorite ...
regards, tom lane
--On Thursday, May 13, 2004 21:26:50 -0400 Tom Lane <tgl@sss.pgh.pa.us>
wrote:
Larry Rosenman <ler@lerctr.org> writes:
I ran a quick C test:
Where does it leave the "ptr" pointing to?
$ cc -O -o test3 test3.c
$ ./test3
num=nan
errno=0
ptr=8049682, points to N
num=inf
errno=0
ptr=8049686, points to f
$ cat test3.c
#include <stdlib.h>
#include <stdio.h>
#include <errno.h>
int main(int argc,char **argv)
{
double num;
char *input="NaN";
char *border1="/////////////////////////////";
char *input2="inf";
char *border2="/////////////////////////////";
char **ptr;
num=strtod(input,ptr);
printf("num=%g\n",num);
printf("errno=%ld\n",errno);
printf("ptr=%p, points to %s\n",*ptr,*ptr);
num=strtod(input2,ptr);
printf("num=%g\n",num);
printf("errno=%ld\n",errno);
printf("ptr=%p, points to %s\n",*ptr,*ptr);
exit(0);
}
$
So, how's the easiest way to trace PG's float4in stuff?
gdb is my favorite ...
and (without installing it), how can I grab gdb on the gmake test
backend(s)?
--
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:
Where does it leave the "ptr" pointing to?
$ ./test3
ptr=8049682, points to N
ptr=8049686, points to f
Indeed, they found an original new way to get it wrong. Please point
out to them that the ptr is supposed to be advanced *past* the input.
Not to the last character of the input.
regards, tom lane
--On Thursday, May 13, 2004 21:35:43 -0400 Tom Lane <tgl@sss.pgh.pa.us>
wrote:
Larry Rosenman <ler@lerctr.org> writes:
Where does it leave the "ptr" pointing to?
$ ./test3
ptr=8049682, points to N
ptr=8049686, points to fIndeed, they found an original new way to get it wrong. Please point
out to them that the ptr is supposed to be advanced *past* the input.
Not to the last character of the input.
Reported to my SCO contacts. However, I guarantee this won't be fixed in
7.1.4 (the next release), as it just went Gold.
Also, I suspect 7.1.3 and below have the bug, and are prevalent.
And, I just proved it on my 7.1.2 (AKA OpenUNIX 8.0.0) system:
$ cc -O -o test3 test3.c
$ ./test3
num=nan
errno=0
ptr=8049682, points to N
num=inf
errno=0
ptr=8049686, points to f
$ uname -a
OpenUNIX lerlsof 5 8.0.0 i386 x86at Caldera UNIX_SVR5
$
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
--
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:
Reply from SCO:
Indeed. For "inf", "infinity", and "nan", but not
"nan(digits)", the pointer is left at the trailing
matched character instead of the next.
Moreover, checking our source history, it has been
broken this way for nearly 12 years. Couldn't you
folks have noticed this bug a little sooner!? :-)
Doesn't give one a warm feeling for the average level of error checking
in Unix programs, does it?
I gather from this that it will be fixed in the first maint packs
for 7.1.4.
Good. I'd say we just leave it for that then.
Is there some way we can work around this?
I don't want to, because it would compromise the error checking.
For instance, if we hack the code to accept this behavior, then
it would also accept "NaNN" as soon as SCO fixes their bug.
The regression tests exist to discover platform bugs as well as
Postgres bugs. In this case, I think having them fail on unpatched
SCO platforms is exactly what should happen.
If you want, you can send in a docs patch for FAQ_SCO to give
people a clue about it.
regards, tom lane
Import Notes
Reply to msg id not found: 248A0D4C55B41D0E211C4E95@lerlaptop.lerctr.org
--On Friday, May 14, 2004 09:41:58 -0400 Tom Lane <tgl@sss.pgh.pa.us> wrote:
Larry Rosenman <ler@lerctr.org> writes:
Reply from SCO:
Indeed. For "inf", "infinity", and "nan", but not
"nan(digits)", the pointer is left at the trailing
matched character instead of the next.Moreover, checking our source history, it has been
broken this way for nearly 12 years. Couldn't you
folks have noticed this bug a little sooner!? :-)Doesn't give one a warm feeling for the average level of error checking
in Unix programs, does it?
nope....
I gather from this that it will be fixed in the first maint packs
for 7.1.4.Good. I'd say we just leave it for that then.
Ok, but see below.
Is there some way we can work around this?
I don't want to, because it would compromise the error checking.
For instance, if we hack the code to accept this behavior, then
it would also accept "NaNN" as soon as SCO fixes their bug.
Won't this change behaviour for
select 'NaN'::float8
etc such that Applications might fail?
The regression tests exist to discover platform bugs as well as
Postgres bugs. In this case, I think having them fail on unpatched
SCO platforms is exactly what should happen.
If you want, you can send in a docs patch for FAQ_SCO to give
people a clue about it.
OK. See above comment, etc.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
--
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