
Everything looks like it built clean ... will do a quick, more general
announce tomorrow, but if someone can confirm that things are good, that
would be great ...

Wed, 27 Aug 2003 00:21:23 -0300 (ADT)
"Marc G. Fournier" <scrappy@postgresql.org>
Beta2 Tag'd and Bundled ...


--On Wednesday, August 27, 2003 00:21:23 -0300 "Marc G. Fournier" 
<scrappy@postgresql.org> wrote:

>
> Everything looks like it built clean ... will do a quick, more general
> announce tomorrow, but if someone can confirm that things are good, that
> would be great ...
My UnixWare Thread.c patch/fix has been IGNORED.

I'd like to see a fix before we declare Beta2.


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


Wed, 27 Aug 2003 23:44:00 -0500
Larry Rosenman <ler@lerctr.org>
Re: Beta2 Tag'd and Bundled ...
Larry Rosenman <ler@lerctr.org> writes:
> My UnixWare Thread.c patch/fix has been IGNORED.
> I'd like to see a fix before we declare Beta2.

Beta2 is a done deal.  When Bruce gets back from the seashore I expect
he'll take a look at the issues you raised, but we're not holding off
beta2 another week for that to happen.

			regards, tom lane

Thu, 28 Aug 2003 01:06:46 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Beta2 Tag'd and Bundled ... 


--On Thursday, August 28, 2003 01:06:46 -0400 Tom Lane <tgl@sss.pgh.pa.us> 
wrote:

> Larry Rosenman <ler@lerctr.org> writes:
>> My UnixWare Thread.c patch/fix has been IGNORED.
>> I'd like to see a fix before we declare Beta2.
>
> Beta2 is a done deal.  When Bruce gets back from the seashore I expect
> he'll take a look at the issues you raised, but we're not holding off
> beta2 another week for that to happen.
I was under the impression he was working on it.

We are shipping a broken template/unixware due to bad spaces....


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


Thu, 28 Aug 2003 06:19:54 -0500
Larry Rosenman <ler@lerctr.org>
Re: Beta2 Tag'd and Bundled ... 
Tom Lane writes:

> Beta2 is a done deal.  When Bruce gets back from the seashore I expect
> he'll take a look at the issues you raised, but we're not holding off
> beta2 another week for that to happen.

Could someone tell the rest of the world ahead of time when release steps
are going to happen?

-- 
Peter Eisentraut   peter_e@gmx.net


Thu, 28 Aug 2003 19:31:17 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: Beta2 Tag'd and Bundled ... 


--On Thursday, August 28, 2003 19:31:17 +0200 Peter Eisentraut 
<peter_e@gmx.net> wrote:

> Tom Lane writes:
>
>> Beta2 is a done deal.  When Bruce gets back from the seashore I expect
>> he'll take a look at the issues you raised, but we're not holding off
>> beta2 another week for that to happen.
>
> Could someone tell the rest of the world ahead of time when release steps
> are going to happen?

AND make sure key people are *NOT UNAVAILABLE* for issues?




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


Thu, 28 Aug 2003 12:32:59 -0500
Larry Rosenman <ler@lerctr.org>
Re: Beta2 Tag'd and Bundled ... 
Larry Rosenman wrote:
> 
> 
> --On Thursday, August 28, 2003 19:31:17 +0200 Peter Eisentraut 
> <peter_e@gmx.net> wrote:
> 
> > Tom Lane writes:
> >
> >> Beta2 is a done deal.  When Bruce gets back from the seashore I expect
> >> he'll take a look at the issues you raised, but we're not holding off
> >> beta2 another week for that to happen.
> >
> > Could someone tell the rest of the world ahead of time when release steps
> > are going to happen?
> 
> AND make sure key people are *NOT UNAVAILABLE* for issues?

Larry, you keep going in this direction and I will think about pulling
thread support for Unixware, and the rest of the group might cheer! (SCO
== Unixware)  In fact, my just saying someone else has to handle the
Unixware threading issues might kill it right there.

For the record, per platform threading will probably be in flux even
after the final release as we adjust thing for various threading
libraries/flags.

OK, back to the 1k emails that arrived in the last two days.

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

Fri, 29 Aug 2003 22:58:50 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Beta2 Tag'd and Bundled ...
Larry Rosenman wrote:
> 
> 
> --On Thursday, August 28, 2003 01:06:46 -0400 Tom Lane <tgl@sss.pgh.pa.us> 
> wrote:
> 
> > Larry Rosenman <ler@lerctr.org> writes:
> >> My UnixWare Thread.c patch/fix has been IGNORED.
> >> I'd like to see a fix before we declare Beta2.
> >
> > Beta2 is a done deal.  When Bruce gets back from the seashore I expect
> > he'll take a look at the issues you raised, but we're not holding off
> > beta2 another week for that to happen.
> I was under the impression he was working on it.
> 
> We are shipping a broken template/unixware due to bad spaces....

What bad spaces?  Have you looked at current CVS that went into 7.4?

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

Fri, 29 Aug 2003 23:00:46 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Beta2 Tag'd and Bundled ...


--On Friday, August 29, 2003 22:58:50 -0400 Bruce Momjian 
<pgman@candle.pha.pa.us> wrote:

> Larry Rosenman wrote:
>>
>>
>> --On Thursday, August 28, 2003 19:31:17 +0200 Peter Eisentraut
>> <peter_e@gmx.net> wrote:
>>
>> > Tom Lane writes:
>> >
>> >> Beta2 is a done deal.  When Bruce gets back from the seashore I expect
>> >> he'll take a look at the issues you raised, but we're not holding off
>> >> beta2 another week for that to happen.
>> >
>> > Could someone tell the rest of the world ahead of time when release
>> > steps are going to happen?
>>
>> AND make sure key people are *NOT UNAVAILABLE* for issues?
>
> Larry, you keep going in this direction and I will think about pulling
> thread support for Unixware, and the rest of the group might cheer! (SCO
> == Unixware)  In fact, my just saying someone else has to handle the
> Unixware threading issues might kill it right there.
>
> For the record, per platform threading will probably be in flux even
> after the final release as we adjust thing for various threading
> libraries/flags.
>
> OK, back to the 1k emails that arrived in the last two days.


Don't start on the SCO issue.  I submitted patches last weekend to fix the
UnixWare (and possibly other) issues.

You said you were working on them, then I see the note that BETA2 was tagged
with INVALID shell code in src/templates/unixware, and
the per-platform threading stuff BROKEN on UnixWare.

When I left for Las Vegas on 8/16, it was **WORKING**.  You committed a 
change
that BROKE it again.

Yes, I'm pissed.

UnixWare==SCO, but the Court fight has **NOTHING** to do with this issue.

Does the PG core not care anymore about **QUALITY**?

I'm NOT going to stand idly by as the SCO/IBM/RED HAT Legal issues are used 
to
hurt PostgreSQL's quality.

I'm NOT very pleased.



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


Fri, 29 Aug 2003 22:04:27 -0500
Larry Rosenman <ler@lerctr.org>
Re: Beta2 Tag'd and Bundled ...


--On Friday, August 29, 2003 23:00:46 -0400 Bruce Momjian 
<pgman@candle.pha.pa.us> wrote:

> Larry Rosenman wrote:
>>
>>
>> --On Thursday, August 28, 2003 01:06:46 -0400 Tom Lane
>> <tgl@sss.pgh.pa.us>  wrote:
>>
>> > Larry Rosenman <ler@lerctr.org> writes:
>> >> My UnixWare Thread.c patch/fix has been IGNORED.
>> >> I'd like to see a fix before we declare Beta2.
>> >
>> > Beta2 is a done deal.  When Bruce gets back from the seashore I expect
>> > he'll take a look at the issues you raised, but we're not holding off
>> > beta2 another week for that to happen.
>> I was under the impression he was working on it.
>>
>> We are shipping a broken template/unixware due to bad spaces....
>
> What bad spaces?  Have you looked at current CVS that went into 7.4?

SUPPORTS_THREADS=yes
NEED_REENTRANT_FUNC_NAMES=yes
THREAD_CFLAGS = "$THREAD_CFLAGS -D_REENTRANT"
$

note the last line before the prompt.



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


Fri, 29 Aug 2003 22:08:14 -0500
Larry Rosenman <ler@lerctr.org>
Re: Beta2 Tag'd and Bundled ...


> Does the PG core not care anymore about **QUALITY**?

Ummm, I believe that is why we are still in Beta, and not at a Release
Candidate stage ... cause there are still bugs, with Unixware obviously
being one of them ...


Sat, 30 Aug 2003 00:09:51 -0300 (ADT)
"Marc G. Fournier" <scrappy@hub.org>
Re: Beta2 Tag'd and Bundled ...


--On Saturday, August 30, 2003 00:09:51 -0300 "Marc G. Fournier" 
<scrappy@hub.org> wrote:

>
>
>> Does the PG core not care anymore about **QUALITY**?
>
> Ummm, I believe that is why we are still in Beta, and not at a Release
> Candidate stage ... cause there are still bugs, with Unixware obviously
> being one of them ...

So be it, but I was under the impression that the fix would be committed 
shortly after
I posted it on LAST SATURDAY, but apparently Bruce was out of town, and the 
Beta2 TAG
was laid, WITHOUT PUBLIC NOTICE about the TAG coming.

Then the SCO/IBM/RED HAT lawsuits are thrown in my face for complaining
about these facts.

I want to see PostgreSQL succeed and take over the Open Source DataBase 
world, and
want to help, but y'all are making it HARD.

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


Fri, 29 Aug 2003 22:12:39 -0500
Larry Rosenman <ler@lerctr.org>
Re: Beta2 Tag'd and Bundled ...
Larry Rosenman wrote:
> Don't start on the SCO issue.  I submitted patches last weekend to fix the
> UnixWare (and possibly other) issues.
> 
> You said you were working on them, then I see the note that BETA2 was tagged
> with INVALID shell code in src/templates/unixware, and
> the per-platform threading stuff BROKEN on UnixWare.
> 
> When I left for Las Vegas on 8/16, it was **WORKING**.  You committed a 
> change
> that BROKE it again.
> 
> Yes, I'm pissed.
> 
> UnixWare==SCO, but the Court fight has **NOTHING** to do with this issue.
> 
> Does the PG core not care anymore about **QUALITY**?
> 
> I'm NOT going to stand idly by as the SCO/IBM/RED HAT Legal issues are used 
> to
> hurt PostgreSQL's quality.
> 
> I'm NOT very pleased.

SCO's threading support in a beta release is about number 2000 on my
list of priorities right now.  It will work in final --- that's all I
can promise.  If that isn't good enough, find someone else who wants to
do the work for you.

I am avoiding fixing the SCO port because it would ugilify the other
ports --- we need to discuss that, not ram in a fix just to get it
working on one platform --- that is quality.

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

Fri, 29 Aug 2003 23:17:50 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Beta2 Tag'd and Bundled ...


--On Friday, August 29, 2003 23:17:50 -0400 Bruce Momjian 
<pgman@candle.pha.pa.us> wrote:

> Larry Rosenman wrote:
>> Don't start on the SCO issue.  I submitted patches last weekend to fix
>> the UnixWare (and possibly other) issues.
>>
>> You said you were working on them, then I see the note that BETA2 was
>> tagged with INVALID shell code in src/templates/unixware, and
>> the per-platform threading stuff BROKEN on UnixWare.
>>
>> When I left for Las Vegas on 8/16, it was **WORKING**.  You committed a
>> change
>> that BROKE it again.
>>
>> Yes, I'm pissed.
>>
>> UnixWare==SCO, but the Court fight has **NOTHING** to do with this issue.
>>
>> Does the PG core not care anymore about **QUALITY**?
>>
>> I'm NOT going to stand idly by as the SCO/IBM/RED HAT Legal issues are
>> used  to
>> hurt PostgreSQL's quality.
>>
>> I'm NOT very pleased.
>
> SCO's threading support in a beta release is about number 2000 on my
> list of priorities right now.  It will work in final --- that's all I
> can promise.  If that isn't good enough, find someone else who wants to
> do the work for you.
>
> I am avoiding fixing the SCO port because it would ugilify the other
> ports --- we need to discuss that, not ram in a fix just to get it
> working on one platform --- that is quality.

where is the discussion happening?




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


Fri, 29 Aug 2003 22:19:18 -0500
Larry Rosenman <ler@lerctr.org>
Re: Beta2 Tag'd and Bundled ...

> So be it, but I was under the impression that the fix would be committed
> shortly after I posted it on LAST SATURDAY, but apparently Bruce was out
> of town, and the Beta2 TAG was laid, WITHOUT PUBLIC NOTICE about the TAG
> coming.

Beta2 TAG was laid so that we could wrap up all fixes to date, of which
yours for unixware hadn't been included yet ... it had been 3 weeks since
Beta1, there were alot of changes, and if ppl are testing based on the tar
ball and not straight CVS, chances are most bugs reported had already been
fixed ...

> Then the SCO/IBM/RED HAT lawsuits are thrown in my face for complaining
> about these facts.

This was uncalled for, but so were your comments over one patch ...

> I want to see PostgreSQL succeed and take over the Open Source DataBase
> world, and want to help, but y'all are making it HARD.

Because one patch wasn't committed before we tar'd up a new beta?

Sat, 30 Aug 2003 00:19:49 -0300 (ADT)
"Marc G. Fournier" <scrappy@hub.org>
Re: Beta2 Tag'd and Bundled ...
Larry Rosenman wrote:
> 
> 
> --On Friday, August 29, 2003 23:00:46 -0400 Bruce Momjian 
> <pgman@candle.pha.pa.us> wrote:
> 
> > Larry Rosenman wrote:
> >>
> >>
> >> --On Thursday, August 28, 2003 01:06:46 -0400 Tom Lane
> >> <tgl@sss.pgh.pa.us>  wrote:
> >>
> >> > Larry Rosenman <ler@lerctr.org> writes:
> >> >> My UnixWare Thread.c patch/fix has been IGNORED.
> >> >> I'd like to see a fix before we declare Beta2.
> >> >
> >> > Beta2 is a done deal.  When Bruce gets back from the seashore I expect
> >> > he'll take a look at the issues you raised, but we're not holding off
> >> > beta2 another week for that to happen.
> >> I was under the impression he was working on it.
> >>
> >> We are shipping a broken template/unixware due to bad spaces....
> >
> > What bad spaces?  Have you looked at current CVS that went into 7.4?
> 
> SUPPORTS_THREADS=yes
> NEED_REENTRANT_FUNC_NAMES=yes
> THREAD_CFLAGS = "$THREAD_CFLAGS -D_REENTRANT"
> $
> 
> note the last line before the prompt.

Oh, sorry.  Fixed now.  I am always thinking that is a makefile when it
isn't.

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

Fri, 29 Aug 2003 23:20:06 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Beta2 Tag'd and Bundled ...

> SUPPORTS_THREADS=yes
> NEED_REENTRANT_FUNC_NAMES=yes
> THREAD_CFLAGS = "$THREAD_CFLAGS -D_REENTRANT"
> $
>
> note the last line before the prompt.

Check current CVS ... now that Bruce has caught up on his email (or made a
dent in it) after being away, looks like he's committed the fix:

SUPPORTS_THREADS=yes
NEED_REENTRANT_FUNC_NAMES=yes
THREAD_CFLAGS="$THREAD_CFLAGS -D_REENTRANT"



Sat, 30 Aug 2003 00:21:29 -0300 (ADT)
"Marc G. Fournier" <scrappy@hub.org>
Re: Beta2 Tag'd and Bundled ...
Larry Rosenman wrote:
> >> UnixWare==SCO, but the Court fight has **NOTHING** to do with this issue.
> >>
> >> Does the PG core not care anymore about **QUALITY**?
> >>
> >> I'm NOT going to stand idly by as the SCO/IBM/RED HAT Legal issues are
> >> used  to
> >> hurt PostgreSQL's quality.
> >>
> >> I'm NOT very pleased.
> >
> > SCO's threading support in a beta release is about number 2000 on my
> > list of priorities right now.  It will work in final --- that's all I
> > can promise.  If that isn't good enough, find someone else who wants to
> > do the work for you.
> >
> > I am avoiding fixing the SCO port because it would ugilify the other
> > ports --- we need to discuss that, not ram in a fix just to get it
> > working on one platform --- that is quality.
> 
> where is the discussion happening?

That's the problem --- I haven't even had time to collect the
information and post it for comment yet.

Quality is getting the right right, not necessary quickly.  You fix was
put on hold because it was complex (for other platforms) and other
things had higher priority.

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

Fri, 29 Aug 2003 23:22:45 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Beta2 Tag'd and Bundled ...
Marc G. Fournier wrote:
> 
> > SUPPORTS_THREADS=yes
> > NEED_REENTRANT_FUNC_NAMES=yes
> > THREAD_CFLAGS = "$THREAD_CFLAGS -D_REENTRANT"
> > $
> >
> > note the last line before the prompt.
> 
> Check current CVS ... now that Bruce has caught up on his email (or made a
> dent in it) after being away, looks like he's committed the fix:
> 
> SUPPORTS_THREADS=yes
> NEED_REENTRANT_FUNC_NAMES=yes
> THREAD_CFLAGS="$THREAD_CFLAGS -D_REENTRANT"

I didn't realize that space was there until he just posted it --- that I
could have fixed easily.

The major holding point is that SCO is going to require we specify each
*_r function required for threading.  SCO doesn't have strerror_r, but
needs the others.  That is going to be three functions call options to
be defined per platform we support.  I need to know the cleanest way of
attacking that, so I don't break more platforms.

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

Fri, 29 Aug 2003 23:25:06 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Beta2 Tag'd and Bundled ...


--On Saturday, August 30, 2003 00:21:29 -0300 "Marc G. Fournier" 
<scrappy@hub.org> wrote:

>
>> SUPPORTS_THREADS=yes
>> NEED_REENTRANT_FUNC_NAMES=yes
>> THREAD_CFLAGS = "$THREAD_CFLAGS -D_REENTRANT"
>> $
>>
>> note the last line before the prompt.
>
> Check current CVS ... now that Bruce has caught up on his email (or made a
> dent in it) after being away, looks like he's committed the fix:
>
> SUPPORTS_THREADS=yes
> NEED_REENTRANT_FUNC_NAMES=yes
> THREAD_CFLAGS="$THREAD_CFLAGS -D_REENTRANT"
>
he just sent me a note.  That post was from AnonCVS right before I posted.

If what's above is what's in cvs now, we're fine, but we still can't 
--enable-thread-safety
due to the code in thread.c.

I'll shut up now.

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


Fri, 29 Aug 2003 22:25:44 -0500
Larry Rosenman <ler@lerctr.org>
Re: Beta2 Tag'd and Bundled ...


--On Friday, August 29, 2003 23:25:06 -0400 Bruce Momjian 
<pgman@candle.pha.pa.us> wrote:

> Marc G. Fournier wrote:
>>
>> > SUPPORTS_THREADS=yes
>> > NEED_REENTRANT_FUNC_NAMES=yes
>> > THREAD_CFLAGS = "$THREAD_CFLAGS -D_REENTRANT"
>> > $
>> >
>> > note the last line before the prompt.
>>
>> Check current CVS ... now that Bruce has caught up on his email (or made
>> a dent in it) after being away, looks like he's committed the fix:
>>
>> SUPPORTS_THREADS=yes
>> NEED_REENTRANT_FUNC_NAMES=yes
>> THREAD_CFLAGS="$THREAD_CFLAGS -D_REENTRANT"
>
> I didn't realize that space was there until he just posted it --- that I
> could have fixed easily.
>
> The major holding point is that SCO is going to require we specify each
> *_r function required for threading.  SCO doesn't have strerror_r, but
> needs the others.  That is going to be three functions call options to
> be defined per platform we support.  I need to know the cleanest way of
> attacking that, so I don't break more platforms.

Actually, we **ONLY** have getpwuid_r, not gethostbyname_r nor strerror_r

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


Fri, 29 Aug 2003 22:26:43 -0500
Larry Rosenman <ler@lerctr.org>
Re: Beta2 Tag'd and Bundled ...
Larry Rosenman wrote:
> 
> 
> --On Saturday, August 30, 2003 00:21:29 -0300 "Marc G. Fournier" 
> <scrappy@hub.org> wrote:
> 
> >
> >> SUPPORTS_THREADS=yes
> >> NEED_REENTRANT_FUNC_NAMES=yes
> >> THREAD_CFLAGS = "$THREAD_CFLAGS -D_REENTRANT"
> >> $
> >>
> >> note the last line before the prompt.
> >
> > Check current CVS ... now that Bruce has caught up on his email (or made a
> > dent in it) after being away, looks like he's committed the fix:
> >
> > SUPPORTS_THREADS=yes
> > NEED_REENTRANT_FUNC_NAMES=yes
> > THREAD_CFLAGS="$THREAD_CFLAGS -D_REENTRANT"
> >
> he just sent me a note.  That post was from AnonCVS right before I posted.
> 
> If what's above is what's in cvs now, we're fine, but we still can't 
> --enable-thread-safety
> due to the code in thread.c.
> 
> I'll shut up now.

In the followup, I posted why I am holding off on the fix --- it
uglifies other platforms, so we need discussion.

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

Fri, 29 Aug 2003 23:27:02 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Beta2 Tag'd and Bundled ...


--On Saturday, August 30, 2003 00:19:49 -0300 "Marc G. Fournier" 
<scrappy@hub.org> wrote:

>
>> So be it, but I was under the impression that the fix would be committed
>> shortly after I posted it on LAST SATURDAY, but apparently Bruce was out
>> of town, and the Beta2 TAG was laid, WITHOUT PUBLIC NOTICE about the TAG
>> coming.
>
> Beta2 TAG was laid so that we could wrap up all fixes to date, of which
> yours for unixware hadn't been included yet ... it had been 3 weeks since
> Beta1, there were alot of changes, and if ppl are testing based on the tar
> ball and not straight CVS, chances are most bugs reported had already been
> fixed ...
>
>> Then the SCO/IBM/RED HAT lawsuits are thrown in my face for complaining
>> about these facts.
>
> This was uncalled for, but so were your comments over one patch ...
>
>> I want to see PostgreSQL succeed and take over the Open Source DataBase
>> world, and want to help, but y'all are making it HARD.
>
> Because one patch wasn't committed before we tar'd up a new beta?
no, because the SCO/IBM/RED HAT lawsuits keep getting thrown in my face
everytime I ask for UnixWare specific changes.

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


Fri, 29 Aug 2003 22:29:21 -0500
Larry Rosenman <ler@lerctr.org>
Re: Beta2 Tag'd and Bundled ...


On Fri, 29 Aug 2003, Larry Rosenman wrote:

>
>
> --On Saturday, August 30, 2003 00:19:49 -0300 "Marc G. Fournier"
> <scrappy@hub.org> wrote:
>
> >
> >> So be it, but I was under the impression that the fix would be committed
> >> shortly after I posted it on LAST SATURDAY, but apparently Bruce was out
> >> of town, and the Beta2 TAG was laid, WITHOUT PUBLIC NOTICE about the TAG
> >> coming.
> >
> > Beta2 TAG was laid so that we could wrap up all fixes to date, of which
> > yours for unixware hadn't been included yet ... it had been 3 weeks since
> > Beta1, there were alot of changes, and if ppl are testing based on the tar
> > ball and not straight CVS, chances are most bugs reported had already been
> > fixed ...
> >
> >> Then the SCO/IBM/RED HAT lawsuits are thrown in my face for complaining
> >> about these facts.
> >
> > This was uncalled for, but so were your comments over one patch ...
> >
> >> I want to see PostgreSQL succeed and take over the Open Source DataBase
> >> world, and want to help, but y'all are making it HARD.
> >
> > Because one patch wasn't committed before we tar'd up a new beta?
> no, because the SCO/IBM/RED HAT lawsuits keep getting thrown in my face
> everytime I ask for UnixWare specific changes.

'K, since flamewars are just sooooo counter-productive to the task at
hand, can we just drop this and move on?

Larry, can you go to archives and let us know which URL contains the patch
that seems to be 'in question'?  And post it in a seperate thread, so that
it doesn't get lost in this whole degraded thread?



Sat, 30 Aug 2003 00:35:10 -0300 (ADT)
"Marc G. Fournier" <scrappy@hub.org>
Re: Beta2 Tag'd and Bundled ...
--On Saturday, August 30, 2003 00:35:10 -0300 "Marc G. Fournier" 
<scrappy@hub.org> wrote:

>
>
> On Fri, 29 Aug 2003, Larry Rosenman wrote:
>
>>
>>
>> --On Saturday, August 30, 2003 00:19:49 -0300 "Marc G. Fournier"
>> <scrappy@hub.org> wrote:
>>
>> >
>> >> So be it, but I was under the impression that the fix would be
>> >> committed shortly after I posted it on LAST SATURDAY, but apparently
>> >> Bruce was out of town, and the Beta2 TAG was laid, WITHOUT PUBLIC
>> >> NOTICE about the TAG coming.
>> >
>> > Beta2 TAG was laid so that we could wrap up all fixes to date, of which
>> > yours for unixware hadn't been included yet ... it had been 3 weeks
>> > since Beta1, there were alot of changes, and if ppl are testing based
>> > on the tar ball and not straight CVS, chances are most bugs reported
>> > had already been fixed ...
>> >
>> >> Then the SCO/IBM/RED HAT lawsuits are thrown in my face for
>> >> complaining about these facts.
>> >
>> > This was uncalled for, but so were your comments over one patch ...
>> >
>> >> I want to see PostgreSQL succeed and take over the Open Source
>> >> DataBase world, and want to help, but y'all are making it HARD.
>> >
>> > Because one patch wasn't committed before we tar'd up a new beta?
>> no, because the SCO/IBM/RED HAT lawsuits keep getting thrown in my face
>> everytime I ask for UnixWare specific changes.
>
> 'K, since flamewars are just sooooo counter-productive to the task at
> hand, can we just drop this and move on?
>
> Larry, can you go to archives and let us know which URL contains the patch
> that seems to be 'in question'?  And post it in a seperate thread, so that
> it doesn't get lost in this whole degraded thread?
>
Here is the patch as posted again (the src/template/unixware change will 
need minor
mods for today's CVS).

Index: src/port/thread.c
===================================================================
RCS file: /projects/cvsroot/pgsql-server/src/port/thread.c,v
retrieving revision 1.4
diff -u -r1.4 thread.c
--- src/port/thread.c	16 Aug 2003 15:35:51 -0000	1.4
+++ src/port/thread.c	23 Aug 2003 04:29:15 -0000
@@ -68,7 +68,7 @@
 pqGetpwuid(uid_t uid, struct passwd *resultbuf, char *buffer,
 		   size_t buflen, struct passwd **result)
 {
-#if defined(USE_THREADS) && defined(NEED_REENTRANT_FUNC_NAMES)
+#if defined(USE_THREADS) && (defined(NEED_REENTRANT_FUNC_NAMES) || 
defined(HAVE_GETPWUID_R))
 	/*
 	 * Early POSIX draft of getpwuid_r() returns 'struct passwd *'.
 	 *    getpwuid_r(uid, resultbuf, buffer, buflen)
Index: src/template/unixware
===================================================================
RCS file: /projects/cvsroot/pgsql-server/src/template/unixware,v
retrieving revision 1.15
diff -u -r1.15 unixware
--- src/template/unixware	16 Aug 2003 15:35:51 -0000	1.15
+++ src/template/unixware	23 Aug 2003 04:29:15 -0000
@@ -10,5 +10,5 @@
 fi

 SUPPORTS_THREADS=yes
-NEED_REENTRANT_FUNC_NAMES=yes
-THREAD_CFLAGS += -D_REENTRANT
+#NEED_REENTRANT_FUNC_NAMES=yes
+THREAD_CFLAGS="$THREAD_CFLAGS -D_REENTRANT -DHAVE_GETPWUID_R"



-- 
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
Fri, 29 Aug 2003 22:37:39 -0500
Larry Rosenman <ler@lerctr.org>
Re: Beta2 Tag'd and Bundled ...


On Fri, 29 Aug 2003, Larry Rosenman wrote:

> Index: src/port/thread.c
> ===================================================================
> RCS file: /projects/cvsroot/pgsql-server/src/port/thread.c,v
> retrieving revision 1.4
> diff -u -r1.4 thread.c
> --- src/port/thread.c	16 Aug 2003 15:35:51 -0000	1.4
> +++ src/port/thread.c	23 Aug 2003 04:29:15 -0000
> @@ -68,7 +68,7 @@
>  pqGetpwuid(uid_t uid, struct passwd *resultbuf, char *buffer,
>  		   size_t buflen, struct passwd **result)
>  {
> -#if defined(USE_THREADS) && defined(NEED_REENTRANT_FUNC_NAMES)
> +#if defined(USE_THREADS) && (defined(NEED_REENTRANT_FUNC_NAMES) ||
> defined(HAVE_GETPWUID_R))
>  	/*
>  	 * Early POSIX draft of getpwuid_r() returns 'struct passwd *'.
>  	 *    getpwuid_r(uid, resultbuf, buffer, buflen)
> Index: src/template/unixware
> ===================================================================
> RCS file: /projects/cvsroot/pgsql-server/src/template/unixware,v
> retrieving revision 1.15
> diff -u -r1.15 unixware
> --- src/template/unixware	16 Aug 2003 15:35:51 -0000	1.15
> +++ src/template/unixware	23 Aug 2003 04:29:15 -0000
> @@ -10,5 +10,5 @@
>  fi
>
>  SUPPORTS_THREADS=yes
> -NEED_REENTRANT_FUNC_NAMES=yes
> -THREAD_CFLAGS += -D_REENTRANT
> +#NEED_REENTRANT_FUNC_NAMES=yes
> +THREAD_CFLAGS="$THREAD_CFLAGS -D_REENTRANT -DHAVE_GETPWUID_R"

'K, my first question on this is shouldn't GETPWUID_R be checked for in
configure, and not hard coded?

My second one is what exactly does this fix/accomplish?  It looks to me
like the result is the same, but I might be missing something obvious?

Sat, 30 Aug 2003 00:57:45 -0300 (ADT)
"Marc G. Fournier" <scrappy@hub.org>
Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)


--On Saturday, August 30, 2003 00:57:45 -0300 "Marc G. Fournier" 
<scrappy@hub.org> wrote:

>
>
> On Fri, 29 Aug 2003, Larry Rosenman wrote:
>
>> Index: src/port/thread.c
>> ===================================================================
>> RCS file: /projects/cvsroot/pgsql-server/src/port/thread.c,v
>> retrieving revision 1.4
>> diff -u -r1.4 thread.c
>> --- src/port/thread.c	16 Aug 2003 15:35:51 -0000	1.4
>> +++ src/port/thread.c	23 Aug 2003 04:29:15 -0000
>> @@ -68,7 +68,7 @@
>>  pqGetpwuid(uid_t uid, struct passwd *resultbuf, char *buffer,
>>  		   size_t buflen, struct passwd **result)
>>  {
>> -#if defined(USE_THREADS) && defined(NEED_REENTRANT_FUNC_NAMES)
>> +#if defined(USE_THREADS) && (defined(NEED_REENTRANT_FUNC_NAMES) ||
>> defined(HAVE_GETPWUID_R))
>>  	/*
>>  	 * Early POSIX draft of getpwuid_r() returns 'struct passwd *'.
>>  	 *    getpwuid_r(uid, resultbuf, buffer, buflen)
>> Index: src/template/unixware
>> ===================================================================
>> RCS file: /projects/cvsroot/pgsql-server/src/template/unixware,v
>> retrieving revision 1.15
>> diff -u -r1.15 unixware
>> --- src/template/unixware	16 Aug 2003 15:35:51 -0000	1.15
>> +++ src/template/unixware	23 Aug 2003 04:29:15 -0000
>> @@ -10,5 +10,5 @@
>>  fi
>>
>>  SUPPORTS_THREADS=yes
>> -NEED_REENTRANT_FUNC_NAMES=yes
>> -THREAD_CFLAGS += -D_REENTRANT
>> +#NEED_REENTRANT_FUNC_NAMES=yes
>> +THREAD_CFLAGS="$THREAD_CFLAGS -D_REENTRANT -DHAVE_GETPWUID_R"
>
> 'K, my first question on this is shouldn't GETPWUID_R be checked for in
> configure, and not hard coded?
It's not checked for currently in configure, and doesn't get set.  I'm not 
an autoconf
maven.
>
> My second one is what exactly does this fix/accomplish?  It looks to me
> like the result is the same, but I might be missing something obvious?

No, with the change to NEEDS_REENTRANT_FUNC_NAMES, without the || 
defined(HAVE_GETPWUID_R)
magic, we use getpwuid, and not getpwuid_r, which would break in a threaded
app.




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


Fri, 29 Aug 2003 23:00:20 -0500
Larry Rosenman <ler@lerctr.org>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)


On Fri, 29 Aug 2003, Larry Rosenman wrote:

>
>
> --On Saturday, August 30, 2003 00:57:45 -0300 "Marc G. Fournier"
> <scrappy@hub.org> wrote:
>
> >
> >
> > On Fri, 29 Aug 2003, Larry Rosenman wrote:
> >
> >> Index: src/port/thread.c
> >> ===================================================================
> >> RCS file: /projects/cvsroot/pgsql-server/src/port/thread.c,v
> >> retrieving revision 1.4
> >> diff -u -r1.4 thread.c
> >> --- src/port/thread.c	16 Aug 2003 15:35:51 -0000	1.4
> >> +++ src/port/thread.c	23 Aug 2003 04:29:15 -0000
> >> @@ -68,7 +68,7 @@
> >>  pqGetpwuid(uid_t uid, struct passwd *resultbuf, char *buffer,
> >>  		   size_t buflen, struct passwd **result)
> >>  {
> >> -#if defined(USE_THREADS) && defined(NEED_REENTRANT_FUNC_NAMES)
> >> +#if defined(USE_THREADS) && (defined(NEED_REENTRANT_FUNC_NAMES) ||
> >> defined(HAVE_GETPWUID_R))
> >>  	/*
> >>  	 * Early POSIX draft of getpwuid_r() returns 'struct passwd *'.
> >>  	 *    getpwuid_r(uid, resultbuf, buffer, buflen)
> >> Index: src/template/unixware
> >> ===================================================================
> >> RCS file: /projects/cvsroot/pgsql-server/src/template/unixware,v
> >> retrieving revision 1.15
> >> diff -u -r1.15 unixware
> >> --- src/template/unixware	16 Aug 2003 15:35:51 -0000	1.15
> >> +++ src/template/unixware	23 Aug 2003 04:29:15 -0000
> >> @@ -10,5 +10,5 @@
> >>  fi
> >>
> >>  SUPPORTS_THREADS=yes
> >> -NEED_REENTRANT_FUNC_NAMES=yes
> >> -THREAD_CFLAGS += -D_REENTRANT
> >> +#NEED_REENTRANT_FUNC_NAMES=yes
> >> +THREAD_CFLAGS="$THREAD_CFLAGS -D_REENTRANT -DHAVE_GETPWUID_R"
> >
> > 'K, my first question on this is shouldn't GETPWUID_R be checked for in
> > configure, and not hard coded?
> It's not checked for currently in configure, and doesn't get set.  I'm not
> an autoconf
> maven.
> >
> > My second one is what exactly does this fix/accomplish?  It looks to me
> > like the result is the same, but I might be missing something obvious?
>
> No, with the change to NEEDS_REENTRANT_FUNC_NAMES, without the ||
> defined(HAVE_GETPWUID_R) magic, we use getpwuid, and not getpwuid_r,
> which would break in a threaded app.

'K, but why the change to NEEDS_REENTRANT_FUNC_NAMES in the first place?

The thing that has me most confused here is that the end result is the
same with or without the patch, from what I can tell ... the right side of
the && will always resolve to TRUE, before or after the patch ... no?


Sat, 30 Aug 2003 01:09:54 -0300 (ADT)
"Marc G. Fournier" <scrappy@hub.org>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)


--On Saturday, August 30, 2003 01:09:54 -0300 "Marc G. Fournier" 
<scrappy@hub.org> wrote:


>
> 'K, but why the change to NEEDS_REENTRANT_FUNC_NAMES in the first place?
>
> The thing that has me most confused here is that the end result is the
> same with or without the patch, from what I can tell ... the right side of
> the && will always resolve to TRUE, before or after the patch ... no?
I want to conditionalize ONLY getpwuid_r, and not strerror_r and 
gethostbyname_r.

So, I changed the NEED_REENTRANT_FUNC_NAMES to no, or undefined in the
template, and need a configure check to set HAVE_GETPWUID_R, so we will
use getpwuid_r in the ENABLE_THREADS case.

UnixWare does NOT have strerror_r nor does it have gethostbyname_r, and the
libc versions are reentrant in libc, for those 2.  We need to use 
getpwuid_r for
threaded apps.

Does this clarify things?

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


Fri, 29 Aug 2003 23:13:40 -0500
Larry Rosenman <ler@lerctr.org>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
Larry Rosenman wrote:
> 
> 
> --On Saturday, August 30, 2003 01:09:54 -0300 "Marc G. Fournier" 
> <scrappy@hub.org> wrote:
> 
> 
> >
> > 'K, but why the change to NEEDS_REENTRANT_FUNC_NAMES in the first place?
> >
> > The thing that has me most confused here is that the end result is the
> > same with or without the patch, from what I can tell ... the right side of
> > the && will always resolve to TRUE, before or after the patch ... no?
> I want to conditionalize ONLY getpwuid_r, and not strerror_r and 
> gethostbyname_r.
> 
> So, I changed the NEED_REENTRANT_FUNC_NAMES to no, or undefined in the
> template, and need a configure check to set HAVE_GETPWUID_R, so we will
> use getpwuid_r in the ENABLE_THREADS case.
> 
> UnixWare does NOT have strerror_r nor does it have gethostbyname_r, and the
> libc versions are reentrant in libc, for those 2.  We need to use 
> getpwuid_r for
> threaded apps.
> 
> Does this clarify things?

Yes, and that is the complex part because _some_ non-*_r functions are
thread-safe, and some are not.  I have to determine if we have other
such platforms before I figure out how to fix it in the cleanest way.

In most platforms that are like this, I think, they have all the *_r
functions even if all of them are not required.

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

Sat, 30 Aug 2003 00:17:41 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)


On Sat, 30 Aug 2003, Bruce Momjian wrote:

> Yes, and that is the complex part because _some_ non-*_r functions are
> thread-safe, and some are not.  I have to determine if we have other
> such platforms before I figure out how to fix it in the cleanest way.

Long shot ... is there some way of writing a configure test for this?
Right now, it sounds like we're going to be hitting alot of trial-n-error
if there isn't ...

Sat, 30 Aug 2003 01:32:22 -0300 (ADT)
"Marc G. Fournier" <scrappy@hub.org>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)


--On Saturday, August 30, 2003 00:17:41 -0400 Bruce Momjian 
<pgman@candle.pha.pa.us> wrote:

> Larry Rosenman wrote:
>>
>>
>> --On Saturday, August 30, 2003 01:09:54 -0300 "Marc G. Fournier"
>> <scrappy@hub.org> wrote:
>>
>>
>> >
>> > 'K, but why the change to NEEDS_REENTRANT_FUNC_NAMES in the first
>> > place?
>> >
>> > The thing that has me most confused here is that the end result is the
>> > same with or without the patch, from what I can tell ... the right
>> > side of the && will always resolve to TRUE, before or after the patch
>> > ... no?
>> I want to conditionalize ONLY getpwuid_r, and not strerror_r and
>> gethostbyname_r.
>>
>> So, I changed the NEED_REENTRANT_FUNC_NAMES to no, or undefined in the
>> template, and need a configure check to set HAVE_GETPWUID_R, so we will
>> use getpwuid_r in the ENABLE_THREADS case.
>>
>> UnixWare does NOT have strerror_r nor does it have gethostbyname_r, and
>> the libc versions are reentrant in libc, for those 2.  We need to use
>> getpwuid_r for
>> threaded apps.
>>
>> Does this clarify things?
>
> Yes, and that is the complex part because _some_ non-*_r functions are
> thread-safe, and some are not.  I have to determine if we have other
> such platforms before I figure out how to fix it in the cleanest way.
>
> In most platforms that are like this, I think, they have all the *_r
> functions even if all of them are not required.
well, this is not true on FreeBSD.

it does NOT have gethostbyname_r (on 5.1-CURRENT as of last nite).

It does have getpwuid_r and strerror_r.

FWIW.





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


Fri, 29 Aug 2003 23:34:37 -0500
Larry Rosenman <ler@lerctr.org>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
Marc G. Fournier wrote:
> 
> 
> On Sat, 30 Aug 2003, Bruce Momjian wrote:
> 
> > Yes, and that is the complex part because _some_ non-*_r functions are
> > thread-safe, and some are not.  I have to determine if we have other
> > such platforms before I figure out how to fix it in the cleanest way.
> 
> Long shot ... is there some way of writing a configure test for this?
> Right now, it sounds like we're going to be hitting alot of trial-n-error
> if there isn't ...

How would we test if a function is thread-safe?  I can't think of a
reliable way, and hence my warning that this adjusting could take a
while.

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

Sat, 30 Aug 2003 00:49:11 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
Larry Rosenman wrote:
> > Yes, and that is the complex part because _some_ non-*_r functions are
> > thread-safe, and some are not.  I have to determine if we have other
> > such platforms before I figure out how to fix it in the cleanest way.
> >
> > In most platforms that are like this, I think, they have all the *_r
> > functions even if all of them are not required.
> well, this is not true on FreeBSD.
> 
> it does NOT have gethostbyname_r (on 5.1-CURRENT as of last nite).
> 
> It does have getpwuid_r and strerror_r.

Yes, but it doesn't require those *_r functions.  It uses a separate
library.  It has them around only for compatibility, or so I am told.

Seems netbsd also needs them, but it seems it has them all.

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

Sat, 30 Aug 2003 00:51:01 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)


--On Saturday, August 30, 2003 00:51:01 -0400 Bruce Momjian 
<pgman@candle.pha.pa.us> wrote:

> Larry Rosenman wrote:
>> > Yes, and that is the complex part because _some_ non-*_r functions are
>> > thread-safe, and some are not.  I have to determine if we have other
>> > such platforms before I figure out how to fix it in the cleanest way.
>> >
>> > In most platforms that are like this, I think, they have all the *_r
>> > functions even if all of them are not required.
>> well, this is not true on FreeBSD.
>>
>> it does NOT have gethostbyname_r (on 5.1-CURRENT as of last nite).
>>
>> It does have getpwuid_r and strerror_r.
>
> Yes, but it doesn't require those *_r functions.  It uses a separate
> library.  It has them around only for compatibility, or so I am told.
>
> Seems netbsd also needs them, but it seems it has them all.

The only two platforms I have are FreeBSD and UnixWare.

So, I can't help more here.





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


Sat, 30 Aug 2003 00:08:45 -0500
Larry Rosenman <ler@lerctr.org>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
Bruce Momjian writes:
 > Marc G. Fournier wrote:
 > > On Sat, 30 Aug 2003, Bruce Momjian wrote:
 > > 
 > > > Yes, and that is the complex part because _some_ non-*_r functions are
 > > > thread-safe, and some are not.  I have to determine if we have other
 > > > such platforms before I figure out how to fix it in the cleanest way.
 > > 
 > > Long shot ... is there some way of writing a configure test for this?
 > > Right now, it sounds like we're going to be hitting alot of trial-n-error
 > > if there isn't ...
 > 
 > How would we test if a function is thread-safe?  I can't think of a
 > reliable way, and hence my warning that this adjusting could take a
 > while.

You don't... and you simply shouldn't care. If there is a_r version
available then we should use it - even if the plain version is "safe".

Just think of this as is it were a normal "port" issue. If an OS
doesn't have zxczxc_r() then we need to write a zxczxc_r() wrapper
function which calls zxczxc() and has the same signature as
zxczxc_r().

L.

Sun, 31 Aug 2003 10:37:40 +0100
Lee Kindness <lkindness@csl.co.uk>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
Lee Kindness writes:

> You don't... and you simply shouldn't care. If there is a_r version
> available then we should use it - even if the plain version is "safe".

The problem with this is that the automatic determination (in configure)
whether there is a xxx_r()  version is, in general, fragile.  We cannot
rely on configure saying that xxx_r() doesn't exist, so the plain xxx()
should be good enough.  Else, we'd be shipping claimed-to-be-thread-safe
libraries that might trigger bugs that will be hard to track down.

I don't see any other solution than keeping a database of NEED_XXX_R for
each platform and then requiring these functions to show up before we
declare a library to be thread-safe.  So far we're only dealing with three
functions, to it should be doable.

-- 
Peter Eisentraut   peter_e@gmx.net


Sun, 31 Aug 2003 12:04:58 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
On Sun, Aug 31, 2003 at 12:04:58PM +0200, Peter Eisentraut wrote:
> Lee Kindness writes:
> 
> > You don't... and you simply shouldn't care. If there is a_r version
> > available then we should use it - even if the plain version is "safe".
> 
> The problem with this is that the automatic determination (in configure)
> whether there is a xxx_r()  version is, in general, fragile.  We cannot
> rely on configure saying that xxx_r() doesn't exist, so the plain xxx()
> should be good enough.  Else, we'd be shipping claimed-to-be-thread-safe
> libraries that might trigger bugs that will be hard to track down.

I think you missed a part of his email.  He says that if xxx_r()
isn't available, we should provide an xxx_r() ourself.


Kurt


Sun, 31 Aug 2003 20:15:43 +0200
Kurt Roeckx <Q@ping.be>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
Kurt Roeckx wrote:
> On Sun, Aug 31, 2003 at 12:04:58PM +0200, Peter Eisentraut wrote:
> > Lee Kindness writes:
> > 
> > > You don't... and you simply shouldn't care. If there is a_r version
> > > available then we should use it - even if the plain version is "safe".
> > 
> > The problem with this is that the automatic determination (in configure)
> > whether there is a xxx_r()  version is, in general, fragile.  We cannot
> > rely on configure saying that xxx_r() doesn't exist, so the plain xxx()
> > should be good enough.  Else, we'd be shipping claimed-to-be-thread-safe
> > libraries that might trigger bugs that will be hard to track down.
> 
> I think you missed a part of his email.  He says that if xxx_r()
> isn't available, we should provide an xxx_r() ourself.

The big problem there is that many platforms don't have *_r functions,
and their normal library functions are thread-safe, even if they return
pointers to static memory area.  See the comment at the top of
src/port/thread.c.

Looking at our current setup in src/template:
	
	bsdi:NEED_REENTRANT_FUNC_NAMES=no
	freebsd:NEED_REENTRANT_FUNC_NAMES=no
	linux:NEED_REENTRANT_FUNC_NAMES=yes
	netbsd:NEED_REENTRANT_FUNC_NAMES=no
	osf:NEED_REENTRANT_FUNC_NAMES=no
	unixware:NEED_REENTRANT_FUNC_NAMES=yes

So, the only OS's that want any *_r functions are linux and unixware. 
Linux wants all of them, and Unixware wants (and has) only one of them.

I am leaning to doing an OS define test in thread.c to prevent usage of
the *_r functions they don't have, and mentioning it as a comment in the
template file (until I find another OS that needs this customization).

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

Sun, 31 Aug 2003 21:10:59 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
Peter Eisentraut <peter_e@gmx.net> writes:

> Lee Kindness writes:
> 
> > You don't... and you simply shouldn't care. If there is a_r version
> > available then we should use it - even if the plain version is "safe".
> 
> The problem with this is that the automatic determination (in configure)
> whether there is a xxx_r()  version is, in general, fragile.  We cannot
> rely on configure saying that xxx_r() doesn't exist, so the plain xxx()
> should be good enough.  Else, we'd be shipping claimed-to-be-thread-safe
> libraries that might trigger bugs that will be hard to track down.

Um. I don't think that's true. I mean, in theory it's true, but in practice
why would an OS have some *_r but have only non-thread-safe versions of
others?

The only OSes like that would be ones that were in the process of developing
thread-safe libraries and hadn't finished yet. Perhaps early versions of
Solaris or CVS snapshots of BSD? I don't know of any actual releases that
anyone would want to be running today.

Postgres doesn't need to work around problems like that. At worst it should
have a blacklist of OS versions that it knows not to even bother building a
threadsafe libpq for.

-- 
greg


01 Sep 2003 10:50:24 -0400
Greg Stark <gsstark@mit.edu>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
Greg Stark wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> 
> > Lee Kindness writes:
> > 
> > > You don't... and you simply shouldn't care. If there is a_r version
> > > available then we should use it - even if the plain version is "safe".
> > 
> > The problem with this is that the automatic determination (in configure)
> > whether there is a xxx_r()  version is, in general, fragile.  We cannot
> > rely on configure saying that xxx_r() doesn't exist, so the plain xxx()
> > should be good enough.  Else, we'd be shipping claimed-to-be-thread-safe
> > libraries that might trigger bugs that will be hard to track down.
> 
> Um. I don't think that's true. I mean, in theory it's true, but in practice
> why would an OS have some *_r but have only non-thread-safe versions of
> others?

Oh, interesting.  So you are saying that if the OS supports threads,
then we use the *_r if they have them, and assume the non *_r functions
are already thread-safe if they don't.  Interesting.

That seems to be what we have on Unixware, and on BSD/OS I have some *_r
functions but not others, but they are all threadsafe, so your plan
works there too.

> The only OSes like that would be ones that were in the process of developing
> thread-safe libraries and hadn't finished yet. Perhaps early versions of
> Solaris or CVS snapshots of BSD? I don't know of any actual releases that
> anyone would want to be running today.
> 
> Postgres doesn't need to work around problems like that. At worst it should
> have a blacklist of OS versions that it knows not to even bother building a
> threadsafe libpq for.

We could go down that road.  The only other OS that needs *_r functions
is Linux, and it uses all *_r functions.  How do we configure to throw
an error in that OS if we don't fined all of them?  Maybe we need a
three-valued variable instead of boolean NEED_REENTRANT_FUNC_NAMES.  We
could call it just REENTRANT_FUNC_NAMES and it could have values
'require', 'prefer', 'disable'.  This mimicks libpq's new PGSSLMODE
values.

That sounds like a clear plan.

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

Mon, 1 Sep 2003 12:35:43 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
Bruce Momjian <pgman@candle.pha.pa.us> writes:

> We could go down that road.  The only other OS that needs *_r functions
> is Linux, and it uses all *_r functions.  How do we configure to throw
> an error in that OS if we don't fined all of them?  Maybe we need a
> three-valued variable instead of boolean NEED_REENTRANT_FUNC_NAMES.  We
> could call it just REENTRANT_FUNC_NAMES and it could have values
> 'require', 'prefer', 'disable'.  This mimicks libpq's new PGSSLMODE
> values.

Actually I don't think that's true for linux. Linux only has *_r functions
that are required, not unnecessary ones.

Note that there are two different types of _r functions being discussed here.

getpwuid, for example, has a thread-safe API. There's really no reason for a
getpwuid_r to exist on any platform. If it exists then it must simply be a
thread-safe version of the regular function. But if it doesn't the regular
function must be thread-safe if the platform supports threads at all.

On the other hand, things like, getpwnam, strtok, etc have non-thread-safe
APIs. They can never be made thread-safe. The *_r versions of these functions
are standardized and required. If they don't exist then the platform simply
does not support threads.

My questions are:

Are there OSes that have strtok_r et al. because standards require them but
have no OS threads support at all? In which case the library would be
"thread-safe" but not really usefully so.

Are there OSes that have extraneous *_r functions like getpwuid_r but only for
compatibility and they're deprecated?


-- 
greg


01 Sep 2003 12:49:59 -0400
Greg Stark <gsstark@mit.edu>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
Greg Stark wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> 
> > We could go down that road.  The only other OS that needs *_r functions
> > is Linux, and it uses all *_r functions.  How do we configure to throw
> > an error in that OS if we don't fined all of them?  Maybe we need a
> > three-valued variable instead of boolean NEED_REENTRANT_FUNC_NAMES.  We
> > could call it just REENTRANT_FUNC_NAMES and it could have values
> > 'require', 'prefer', 'disable'.  This mimicks libpq's new PGSSLMODE
> > values.
> 
> Actually I don't think that's true for linux. Linux only has *_r functions
> that are required, not unnecessary ones.
> 
> Note that there are two different types of _r functions being discussed here.
> 
> getpwuid, for example, has a thread-safe API. There's really no reason for a
> getpwuid_r to exist on any platform. If it exists then it must simply be a
> thread-safe version of the regular function. But if it doesn't the regular
> function must be thread-safe if the platform supports threads at all.
> 
> On the other hand, things like, getpwnam, strtok, etc have non-thread-safe
> APIs. They can never be made thread-safe. The *_r versions of these functions
> are standardized and required. If they don't exist then the platform simply
> does not support threads.
> 
> My questions are:
> 
> Are there OSes that have strtok_r et al. because standards require them but
> have no OS threads support at all? In which case the library would be
> "thread-safe" but not really usefully so.
> 
> Are there OSes that have extraneous *_r functions like getpwuid_r but only for
> compatibility and they're deprecated?

Have you read the comment at the top of port/thread.c?  There is a way
to make those thread-safe using per-thread global variables, I think.

Anyway, require doesn't mean we need all the *_r functions that exist,
just that we need the *_r functions that appear in thread.c.

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

Mon, 1 Sep 2003 13:05:46 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)


--On Monday, September 01, 2003 12:35:43 -0400 Bruce Momjian 
<pgman@candle.pha.pa.us> wrote:

>
>> Um. I don't think that's true. I mean, in theory it's true, but in
>> practice why would an OS have some *_r but have only non-thread-safe
>> versions of others?
>
> Oh, interesting.  So you are saying that if the OS supports threads,
> then we use the *_r if they have them, and assume the non *_r functions
> are already thread-safe if they don't.  Interesting.
>
> That seems to be what we have on Unixware, and on BSD/OS I have some *_r
> functions but not others, but they are all threadsafe, so your plan
> works there too.
UnixWare's Kernel is threaded, and I assume anything in libc is threadsafe 
unless
told otherwise.

[snip]
> We could go down that road.  The only other OS that needs *_r functions
> is Linux, and it uses all *_r functions.  How do we configure to throw
> an error in that OS if we don't fined all of them?  Maybe we need a
> three-valued variable instead of boolean NEED_REENTRANT_FUNC_NAMES.  We
> could call it just REENTRANT_FUNC_NAMES and it could have values
> 'require', 'prefer', 'disable'.  This mimicks libpq's new PGSSLMODE
> values.
>
> That sounds like a clear plan.
I have no preference.  I would just like to see a thread-safe libpq.




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


Mon, 01 Sep 2003 12:07:04 -0500
Larry Rosenman <ler@lerctr.org>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
Larry Rosenman wrote:
> 
> 
> --On Monday, September 01, 2003 12:35:43 -0400 Bruce Momjian 
> <pgman@candle.pha.pa.us> wrote:
> 
> >
> >> Um. I don't think that's true. I mean, in theory it's true, but in
> >> practice why would an OS have some *_r but have only non-thread-safe
> >> versions of others?
> >
> > Oh, interesting.  So you are saying that if the OS supports threads,
> > then we use the *_r if they have them, and assume the non *_r functions
> > are already thread-safe if they don't.  Interesting.
> >
> > That seems to be what we have on Unixware, and on BSD/OS I have some *_r
> > functions but not others, but they are all threadsafe, so your plan
> > works there too.
> UnixWare's Kernel is threaded, and I assume anything in libc is threadsafe 
> unless
> told otherwise.

What?  You said Unixware needs getpwuid_r.  And this has nothing to do
with whether the kernel is threaded.

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

Mon, 1 Sep 2003 13:11:25 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)


--On Monday, September 01, 2003 13:11:25 -0400 Bruce Momjian 
<pgman@candle.pha.pa.us> wrote:

> Larry Rosenman wrote:
>>
>>
>> --On Monday, September 01, 2003 12:35:43 -0400 Bruce Momjian
>> <pgman@candle.pha.pa.us> wrote:
>>
>> >
>> >> Um. I don't think that's true. I mean, in theory it's true, but in
>> >> practice why would an OS have some *_r but have only non-thread-safe
>> >> versions of others?
>> >
>> > Oh, interesting.  So you are saying that if the OS supports threads,
>> > then we use the *_r if they have them, and assume the non *_r functions
>> > are already thread-safe if they don't.  Interesting.
>> >
>> > That seems to be what we have on Unixware, and on BSD/OS I have some
>> > *_r functions but not others, but they are all threadsafe, so your plan
>> > works there too.
>> UnixWare's Kernel is threaded, and I assume anything in libc is
>> threadsafe  unless
>> told otherwise.
>
> What?  You said Unixware needs getpwuid_r.  And this has nothing to do
> with whether the kernel is threaded.
right, getpwuid is not threadsafe, so we use the provided getpwuid_r.





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


Mon, 01 Sep 2003 12:13:11 -0500
Larry Rosenman <ler@lerctr.org>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)


On Mon, 1 Sep 2003, Bruce Momjian wrote:

> Larry Rosenman wrote:
> >
> >
> > --On Monday, September 01, 2003 12:35:43 -0400 Bruce Momjian
> > <pgman@candle.pha.pa.us> wrote:
> >
> > >
> > >> Um. I don't think that's true. I mean, in theory it's true, but in
> > >> practice why would an OS have some *_r but have only non-thread-safe
> > >> versions of others?
> > >
> > > Oh, interesting.  So you are saying that if the OS supports threads,
> > > then we use the *_r if they have them, and assume the non *_r functions
> > > are already thread-safe if they don't.  Interesting.
> > >
> > > That seems to be what we have on Unixware, and on BSD/OS I have some *_r
> > > functions but not others, but they are all threadsafe, so your plan
> > > works there too.
> > UnixWare's Kernel is threaded, and I assume anything in libc is threadsafe
> > unless
> > told otherwise.
>
> What?  You said Unixware needs getpwuid_r.  And this has nothing to do
> with whether the kernel is threaded.

Note that Larry said "unless told otherwise", so I'm guessing that there
is somewhere in Unixware taht states that standard getpwuid isn't thread
safe? :)


Mon, 1 Sep 2003 14:24:14 -0300 (ADT)
"Marc G. Fournier" <scrappy@hub.org>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)


--On Monday, September 01, 2003 14:24:14 -0300 "Marc G. Fournier" 
<scrappy@hub.org> wrote:

>
>
> On Mon, 1 Sep 2003, Bruce Momjian wrote:
>
>> Larry Rosenman wrote:
>> >
>> >
>> > --On Monday, September 01, 2003 12:35:43 -0400 Bruce Momjian
>> > <pgman@candle.pha.pa.us> wrote:
>> >
>> > >
>> > >> Um. I don't think that's true. I mean, in theory it's true, but in
>> > >> practice why would an OS have some *_r but have only non-thread-safe
>> > >> versions of others?
>> > >
>> > > Oh, interesting.  So you are saying that if the OS supports threads,
>> > > then we use the *_r if they have them, and assume the non *_r
>> > > functions are already thread-safe if they don't.  Interesting.
>> > >
>> > > That seems to be what we have on Unixware, and on BSD/OS I have some
>> > > *_r functions but not others, but they are all threadsafe, so your
>> > > plan works there too.
>> > UnixWare's Kernel is threaded, and I assume anything in libc is
>> > threadsafe unless
>> > told otherwise.
>>
>> What?  You said Unixware needs getpwuid_r.  And this has nothing to do
>> with whether the kernel is threaded.
>
> Note that Larry said "unless told otherwise", so I'm guessing that there
> is somewhere in Unixware taht states that standard getpwuid isn't thread
> safe? :)
http://www.lerctr.org:8458/en/man/html.3C/getpwent.3C.html
the above is the manual page as used on UnixWare.  See the very end.

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


Mon, 01 Sep 2003 12:25:36 -0500
Larry Rosenman <ler@lerctr.org>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
Guys, too much thought is being spent on this...

1. For the _r functions we "need" we should ALWAYS use them if the
system we are building on has them - they WILL be thread-safe.

2. If the system is missing a _r function then we implement a wrapper
to call the normal non-_r version. However we do NOT make this wrapper
call thread-safe - we assume the non-_r version already is.

Together both steps ensure the code calling the _r function is
readable (just one function signature) and that libpq will be
thread-safe if the system C library is thread-safe. So this will catch
all modern UNIX OSs.

We really don't want to go deeper than this - of we do so we're
wasting time on odd-ball systems that aren't thread-safe anyway - so
for them libpq's thread-safety is of no consequence.

L.

Mon, 1 Sep 2003 18:26:17 +0100
Lee Kindness <lkindness@csl.co.uk>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
Lee Kindness <lkindness@csl.co.uk> writes:
> Guys, too much thought is being spent on this...
> 1. For the _r functions we "need" we should ALWAYS use them if the
> system we are building on has them - they WILL be thread-safe.

> 2. If the system is missing a _r function then we implement a wrapper
> to call the normal non-_r version. However we do NOT make this wrapper
> call thread-safe - we assume the non-_r version already is.

That assumption is exactly what Peter is unhappy about.  With the above
approach we will happily build a "thread safe" library on systems that
are in fact not thread safe at all.  Peter wants --enable-thread-safety
to fail on non-safe systems.

			regards, tom lane

Mon, 01 Sep 2003 16:01:16 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...) 


--On Monday, September 01, 2003 16:01:16 -0400 Tom Lane <tgl@sss.pgh.pa.us> 
wrote:

> Lee Kindness <lkindness@csl.co.uk> writes:
>> Guys, too much thought is being spent on this...
>> 1. For the _r functions we "need" we should ALWAYS use them if the
>> system we are building on has them - they WILL be thread-safe.
>
>> 2. If the system is missing a _r function then we implement a wrapper
>> to call the normal non-_r version. However we do NOT make this wrapper
>> call thread-safe - we assume the non-_r version already is.
>
> That assumption is exactly what Peter is unhappy about.  With the above
> approach we will happily build a "thread safe" library on systems that
> are in fact not thread safe at all.  Peter wants --enable-thread-safety
> to fail on non-safe systems.
then how do we *PROVE* thread-safety on a particular platform?

In my case on UnixWare, we assume all libc is thread-safe except for those 
that
are specifically called out.

the getpwuid() function has a _r version, so we can use that.  the 
gethostbyname and strerror functions do *NOT* have a _r version, but are 
assumed thread-safe.

The current (cvs) version can't build a thread-safe libpq, but with my 
patch it does build.

LER

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


Mon, 01 Sep 2003 15:05:57 -0500
Larry Rosenman <ler@lerctr.org>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
"Tom Lane" <tgl@sss.pgh.pa.us> writes:
> Lee Kindness <lkindness@csl.co.uk> writes:
> > Guys, too much thought is being spent on this...
> > 1. For the _r functions we "need" we should ALWAYS use them if the
> > system we are building on has them - they WILL be thread-safe.
>
> > 2. If the system is missing a _r function then we implement a wrapper
> > to call the normal non-_r version. However we do NOT make this wrapper
> > call thread-safe - we assume the non-_r version already is.
>
> That assumption is exactly what Peter is unhappy about.  With the above
> approach we will happily build a "thread safe" library on systems that
> are in fact not thread safe at all.  Peter wants --enable-thread-safety
> to fail on non-safe systems.

Yeah, I see that as Peter's main objection too. But it really isn't worth
the
trouble, on such systems a user's app will be so horribly broken WRT
threads anyway. It isn't our job to point out the shortcomings of their
system.

Really such systems don't exist - if libc doesn't have _r calls and the
traditional ones are not thread-safe then do you think it'll have a
threading
library which can run >1 thread concurrently?

On such a system the users troubles will start long before PostgreSQL
if they play with threads.

L.


Mon, 1 Sep 2003 21:57:07 +0100
"Lee Kindness" <lkindness@csl.co.uk>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...) 
"Larry Rosenman" <ler@lerctr.org> writes:
> then how do we *PROVE* thread-safety on a particular platform?

You're not going to be able to prove it anyway!

L.

Mon, 1 Sep 2003 22:02:00 +0100
"Lee Kindness" <lkindness@csl.co.uk>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)


--On Monday, September 01, 2003 22:02:00 +0100 Lee Kindness 
<lkindness@csl.co.uk> wrote:

> "Larry Rosenman" <ler@lerctr.org> writes:
>> then how do we *PROVE* thread-safety on a particular platform?
>
> You're not going to be able to prove it anyway!
which is my point.


>
> L.



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


Mon, 01 Sep 2003 16:03:17 -0500
Larry Rosenman <ler@lerctr.org>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
Greg Stark <gsstark@mit.edu> writes:
> On the other hand, things like, getpwnam, strtok, etc have non-thread-safe
> APIs. They can never be made thread-safe. The *_r versions of these functions
> are standardized and required. If they don't exist then the platform simply
> does not support threads.

This statement is simply false.  A platform can build thread-safe
versions of those "unsafe" APIs if it makes the return values point
to thread-local storage.  Some BSDs do it that way.  Accordingly, any
simplistic "we must have _r to be thread-safe" approach is incorrect.

			regards, tom lane

Mon, 01 Sep 2003 17:11:04 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...) 
Tom Lane <tgl@sss.pgh.pa.us> writes:

> Greg Stark <gsstark@mit.edu> writes:
> > On the other hand, things like, getpwnam, strtok, etc have non-thread-safe
> > APIs. They can never be made thread-safe. The *_r versions of these functions
> > are standardized and required. If they don't exist then the platform simply
> > does not support threads.
> 
> This statement is simply false.  A platform can build thread-safe
> versions of those "unsafe" APIs if it makes the return values point
> to thread-local storage.  Some BSDs do it that way.  Accordingly, any
> simplistic "we must have _r to be thread-safe" approach is incorrect.

Except there are standards that describe things like strtok_r and such. If the
OS doesn't have those standard functions at all then it probably doesn't have
a thread-safe strtok. 

Moreover I was somewhat disturbed when I read that in port/thread.c. It seems
rather a dramatic non-standard API change for these functions. It must break
programs and libraries that expect these to have global state accessible from
any thread. I suspect if I check back in the BSD mailing lists there were
flamewars over this at the time.

Generally I would prefer to use standards-dictated _r functions than depend on
non-standard thread-local api extensions. Especially since many platforms have
slow thread-local storage implementations.

In any case I think I'm bowing out of this discussion. It seems like a simple
matter has gotten way out of hand and I feel like a troll here. Sorry for
fueling the confusion.

-- 
greg


01 Sep 2003 17:21:10 -0400
Greg Stark <gsstark@mit.edu>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
Greg Stark writes:

> Um. I don't think that's true. I mean, in theory it's true, but in practice
> why would an OS have some *_r but have only non-thread-safe versions of
> others?

The question is whether configure can reliably identify whether various
*_r functions exist.  I think it can't.  For example, they could be in a
separate library that we don't know about.

-- 
Peter Eisentraut   peter_e@gmx.net


Mon, 1 Sep 2003 23:37:40 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
Tom Lane writes:

> This statement is simply false.  A platform can build thread-safe
> versions of those "unsafe" APIs if it makes the return values point
> to thread-local storage.  Some BSDs do it that way.  Accordingly, any
> simplistic "we must have _r to be thread-safe" approach is incorrect.

That's the difference between being thread-safe and being reentrant.
Reentrancy is (usually) a property of the interface (hence *_r functions
with differing interfaces), thread-safety is a feature of the
implementation; both are orthogonal properties.  The Unix standards sort
of encourage making one dependent on the other, which might be where this
confusion comes from.

-- 
Peter Eisentraut   peter_e@gmx.net


Mon, 1 Sep 2003 23:45:46 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
"Peter Eisentraut" <peter_e@gmx.net> wrote:
> Reentrancy is (usually) a property of the interface (hence *_r functions
> with differing interfaces), thread-safety is a feature of the
> implementation; 

May I not agree with this definition ?

Reentrancy is a property of the implemention that
assure that the code can be executed simultaneously 
by concurrent program.

Thread safety instead involve concept like critical section
and the ability to force the non execution simultaneously
of part of the code.


I agree anyway that are orthogonal concept.


Regards
Gaetano Mendola


Tue, 2 Sep 2003 01:43:28 +0200
"Gaetano Mendola" <mendola@bigfoot.com>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)


On Mon, 1 Sep 2003, Peter Eisentraut wrote:

> Greg Stark writes:
>
> > Um. I don't think that's true. I mean, in theory it's true, but in practice
> > why would an OS have some *_r but have only non-thread-safe versions of
> > others?
>
> The question is whether configure can reliably identify whether various
> *_r functions exist.  I think it can't.  For example, they could be in a
> separate library that we don't know about.

'K,  but isn't that just a matter of adding an extra test when such
'extra libraries' are identified?  I've seen it before, in order
configures, where it tests for the same function in a couple of different
libraries ...


Mon, 1 Sep 2003 20:59:04 -0300 (ADT)
"Marc G. Fournier" <scrappy@hub.org>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
Marc G. Fournier wrote:
> 
> 
> On Mon, 1 Sep 2003, Peter Eisentraut wrote:
> 
> > Greg Stark writes:
> >
> > > Um. I don't think that's true. I mean, in theory it's true, but in practice
> > > why would an OS have some *_r but have only non-thread-safe versions of
> > > others?
> >
> > The question is whether configure can reliably identify whether various
> > *_r functions exist.  I think it can't.  For example, they could be in a
> > separate library that we don't know about.
> 
> 'K,  but isn't that just a matter of adding an extra test when such
> 'extra libraries' are identified?  I've seen it before, in order
> configures, where it tests for the same function in a couple of different
> libraries ...

We do have tests for *_r functions now in configure.in, and it does use
any thread-specific library/compiler flags defined in the OS template.

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

Mon, 1 Sep 2003 22:53:36 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
Larry Rosenman wrote:
> >> > Oh, interesting.  So you are saying that if the OS supports threads,
> >> > then we use the *_r if they have them, and assume the non *_r functions
> >> > are already thread-safe if they don't.  Interesting.
> >> >
> >> > That seems to be what we have on Unixware, and on BSD/OS I have some
> >> > *_r functions but not others, but they are all threadsafe, so your plan
> >> > works there too.
> >> UnixWare's Kernel is threaded, and I assume anything in libc is
> >> threadsafe  unless
> >> told otherwise.
> >
> > What?  You said Unixware needs getpwuid_r.  And this has nothing to do
> > with whether the kernel is threaded.
> right, getpwuid is not threadsafe, so we use the provided getpwuid_r.

Larry, I read the URL you gave me:

        http://www.lerctr.org:8458/en/man/html.3C/getpwent.3C.html

Where does it say that you have to use getpwuid_r() to be thread safe? 
I don't see any mention in the docs.  It does say about getpwuid:

	For getpwent, getpwuid, getpwnam, setpwent, endpwent, and
	fgetpwent, all information is contained in a static area, so it must be
	copied if it is to be

but that in itself doesn't mean it isn't thread safe.  If you are not
sure, would you write a little thread program to test if it works if two
threads try it at the same time.

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

Tue, 2 Sep 2003 00:04:35 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)


--On Tuesday, September 02, 2003 00:04:35 -0400 Bruce Momjian 
<pgman@candle.pha.pa.us> wrote:

> Larry Rosenman wrote:
>> >> > Oh, interesting.  So you are saying that if the OS supports threads,
>> >> > then we use the *_r if they have them, and assume the non *_r
>> >> > functions are already thread-safe if they don't.  Interesting.
>> >> >
>> >> > That seems to be what we have on Unixware, and on BSD/OS I have some
>> >> > *_r functions but not others, but they are all threadsafe, so your
>> >> > plan works there too.
>> >> UnixWare's Kernel is threaded, and I assume anything in libc is
>> >> threadsafe  unless
>> >> told otherwise.
>> >
>> > What?  You said Unixware needs getpwuid_r.  And this has nothing to do
>> > with whether the kernel is threaded.
>> right, getpwuid is not threadsafe, so we use the provided getpwuid_r.
>
> Larry, I read the URL you gave me:
>
>         http://www.lerctr.org:8458/en/man/html.3C/getpwent.3C.html
>
> Where does it say that you have to use getpwuid_r() to be thread safe?
> I don't see any mention in the docs.  It does say about getpwuid:
>
> 	For getpwent, getpwuid, getpwnam, setpwent, endpwent, and
> 	fgetpwent, all information is contained in a static area, so it must be
> 	copied if it is to be
>
> but that in itself doesn't mean it isn't thread safe.  If you are not
> sure, would you write a little thread program to test if it works if two
> threads try it at the same time.
I only have a UP box.

Since the _r version uses OUR OWN buffer, it is safer to use the _r version.

Since we do NOT have the _r alternative for strerror and gethostbyname, 
that's the
best we can do.




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


Tue, 02 Sep 2003 00:24:07 -0500
Larry Rosenman <ler@lerctr.org>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
Tom Lane writes:
 > Greg Stark <gsstark@mit.edu> writes:
 > > On the other hand, things like, getpwnam, strtok, etc have non-thread-safe
 > > APIs. They can never be made thread-safe. The *_r versions of these functions
 > > are standardized and required. If they don't exist then the platform simply
 > > does not support threads.
 > 
 > This statement is simply false.  A platform can build thread-safe
 > versions of those "unsafe" APIs if it makes the return values point
 > to thread-local storage.  Some BSDs do it that way.  Accordingly, any
 > simplistic "we must have _r to be thread-safe" approach is
 > incorrect.

No, it's not. Using the _r functions on such systems is BETTER because
the API is clean and the function can be implmented in a reentrant and
thread-safe fashion wuithout the need for thread local storage or
mutex locking.

L.

Tue, 2 Sep 2003 09:08:49 +0100
Lee Kindness <lkindness@csl.co.uk>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...) 
Lee Kindness writes:
 > Tom Lane writes:
 >  > Greg Stark <gsstark@mit.edu> writes:
 >  > > On the other hand, things like, getpwnam, strtok, etc have non-thread-safe
 >  > > APIs. They can never be made thread-safe. The *_r versions of these functions
 >  > > are standardized and required. If they don't exist then the platform simply
 >  > > does not support threads.
 >  > 
 >  > This statement is simply false.  A platform can build thread-safe
 >  > versions of those "unsafe" APIs if it makes the return values point
 >  > to thread-local storage.  Some BSDs do it that way.  Accordingly, any
 >  > simplistic "we must have _r to be thread-safe" approach is
 >  > incorrect.
 > 
 > No, it's not. Using the _r functions on such systems is BETTER because
 > the API is clean and the function can be implmented in a reentrant and
 > thread-safe fashion wuithout the need for thread local storage or
 > mutex locking.

Sorry Tom, I should have read a bit more carefully! Yeah, I agree with
your point that the lack of _r functions doesn't mean the platform is
non thread-safe!

L.

Tue, 2 Sep 2003 11:49:28 +0100
Lee Kindness <lkindness@csl.co.uk>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...) 
Peter Eisentraut wrote:
> Lee Kindness writes:
> 
> > You don't... and you simply shouldn't care. If there is a_r version
> > available then we should use it - even if the plain version is "safe".
> 
> The problem with this is that the automatic determination (in configure)
> whether there is a xxx_r()  version is, in general, fragile.  We cannot
> rely on configure saying that xxx_r() doesn't exist, so the plain xxx()
> should be good enough.  Else, we'd be shipping claimed-to-be-thread-safe
> libraries that might trigger bugs that will be hard to track down.
> 
> I don't see any other solution than keeping a database of NEED_XXX_R for
> each platform and then requiring these functions to show up before we
> declare a library to be thread-safe.  So far we're only dealing with three
> functions, to it should be doable.

Right.  We can't assume because a *_r function is missing that the
normal function is thread-safe.

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

Tue, 2 Sep 2003 11:20:14 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
Lee Kindness wrote:
> Tom Lane writes:
>  > Greg Stark <gsstark@mit.edu> writes:
>  > > On the other hand, things like, getpwnam, strtok, etc have non-thread-safe
>  > > APIs. They can never be made thread-safe. The *_r versions of these functions
>  > > are standardized and required. If they don't exist then the platform simply
>  > > does not support threads.
>  > 
>  > This statement is simply false.  A platform can build thread-safe
>  > versions of those "unsafe" APIs if it makes the return values point
>  > to thread-local storage.  Some BSDs do it that way.  Accordingly, any
>  > simplistic "we must have _r to be thread-safe" approach is
>  > incorrect.
> 
> No, it's not. Using the _r functions on such systems is BETTER because
> the API is clean and the function can be implmented in a reentrant and
> thread-safe fashion wuithout the need for thread local storage or
> mutex locking.

I don't care about overhead at this point.  These functions are rarely
called.

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

Tue, 2 Sep 2003 11:21:27 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)


--On Tuesday, September 02, 2003 11:20:14 -0400 Bruce Momjian 
<pgman@candle.pha.pa.us> wrote:

> Peter Eisentraut wrote:
>> Lee Kindness writes:
>>
>> > You don't... and you simply shouldn't care. If there is a_r version
>> > available then we should use it - even if the plain version is "safe".
>>
>> The problem with this is that the automatic determination (in configure)
>> whether there is a xxx_r()  version is, in general, fragile.  We cannot
>> rely on configure saying that xxx_r() doesn't exist, so the plain xxx()
>> should be good enough.  Else, we'd be shipping claimed-to-be-thread-safe
>> libraries that might trigger bugs that will be hard to track down.
>>
>> I don't see any other solution than keeping a database of NEED_XXX_R for
>> each platform and then requiring these functions to show up before we
>> declare a library to be thread-safe.  So far we're only dealing with
>> three functions, to it should be doable.
>
> Right.  We can't assume because a *_r function is missing that the
> normal function is thread-safe.
So, given that UnixWare doesn't have gethostbyname_r and strerror_r, but 
does have
getpwuid_r, will y'all declare that UnixWare has thread-safety?

My vote is YES.

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


Tue, 02 Sep 2003 10:24:22 -0500
Larry Rosenman <ler@lerctr.org>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
Larry Rosenman wrote:
> > Where does it say that you have to use getpwuid_r() to be thread safe?
> > I don't see any mention in the docs.  It does say about getpwuid:
> >
> >      For getpwent, getpwuid, getpwnam, setpwent, endpwent, and
> >      fgetpwent, all information is contained in a static area, so it must be
> >      copied if it is to be
> >
> > but that in itself doesn't mean it isn't thread safe.  If you are not
> > sure, would you write a little thread program to test if it works if two
> > threads try it at the same time.
> I only have a UP box.
> 
> Since the _r version uses OUR OWN buffer, it is safer to use
> the _r version.
> 
> Since we do NOT have the _r alternative for strerror and
> gethostbyname, that's the best we can do.

Uh, that's not the logic I use.  I have some *_r functions on BSD/OS,
but the normal libc functions are thread-safe, so I just use those.  I
think I have the *_r functions because the standards require them to
exist, not because they are required for thread-safety, and like
Unixware, I have some of them, but not others (no strerror_r).  Because
Unixware is similar in that it has some *_r functions and not others, I
want to know if getpwuid_r() is required.

gethostbyname() also returns data from a static area.  Why is that
thread-safe on Unixware and getpwuid() is not?  My guess is that both
are thread-safe but some software requires getpwuid_r() so they added
it.  Again, on those OS's, it is better to just use the libc versions.

"Safer" isn't an issue.  Either it is safe or unsafe.  I also don't care
about locking overhead in the libc versions of these functions.

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

Tue, 2 Sep 2003 11:32:08 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)


--On Tuesday, September 02, 2003 11:32:08 -0400 Bruce Momjian 
<pgman@candle.pha.pa.us> wrote:

> Larry Rosenman wrote:
>> > Where does it say that you have to use getpwuid_r() to be thread safe?
>> > I don't see any mention in the docs.  It does say about getpwuid:
>> >
>> >      For getpwent, getpwuid, getpwnam, setpwent, endpwent, and
>> >      fgetpwent, all information is contained in a static area, so it
>> >      must be copied if it is to be
>> >
>> > but that in itself doesn't mean it isn't thread safe.  If you are not
>> > sure, would you write a little thread program to test if it works if
>> > two threads try it at the same time.
>> I only have a UP box.
>>
>> Since the _r version uses OUR OWN buffer, it is safer to use
>> the _r version.
>>
>> Since we do NOT have the _r alternative for strerror and
>> gethostbyname, that's the best we can do.
>
> Uh, that's not the logic I use.  I have some *_r functions on BSD/OS,
> but the normal libc functions are thread-safe, so I just use those.  I
> think I have the *_r functions because the standards require them to
> exist, not because they are required for thread-safety, and like
> Unixware, I have some of them, but not others (no strerror_r).  Because
> Unixware is similar in that it has some *_r functions and not others, I
> want to know if getpwuid_r() is required.
>
> gethostbyname() also returns data from a static area.  Why is that
> thread-safe on Unixware and getpwuid() is not?  My guess is that both
> are thread-safe but some software requires getpwuid_r() so they added
> it.  Again, on those OS's, it is better to just use the libc versions.
>
> "Safer" isn't an issue.  Either it is safe or unsafe.  I also don't care
> about locking overhead in the libc versions of these functions.
My take is unless otherwise stated, all libc functions are thread-safe on 
UnixWare.
the *_r functions are better if available as they require the USER to 
allocate/pass
their OWN buffer.  We should use those (that's the signature we use in 
src/port/thread.c),
but if they don't exist, we should just use the non-*_r version.

If the OS supports threads, this *should* work.

My $0.02.

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


Tue, 02 Sep 2003 10:34:51 -0500
Larry Rosenman <ler@lerctr.org>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
Larry Rosenman wrote:
> 
> 
> --On Tuesday, September 02, 2003 11:20:14 -0400 Bruce Momjian 
> <pgman@candle.pha.pa.us> wrote:
> 
> > Peter Eisentraut wrote:
> >> Lee Kindness writes:
> >>
> >> > You don't... and you simply shouldn't care. If there is a_r version
> >> > available then we should use it - even if the plain version is "safe".
> >>
> >> The problem with this is that the automatic determination (in configure)
> >> whether there is a xxx_r()  version is, in general, fragile.  We cannot
> >> rely on configure saying that xxx_r() doesn't exist, so the plain xxx()
> >> should be good enough.  Else, we'd be shipping claimed-to-be-thread-safe
> >> libraries that might trigger bugs that will be hard to track down.
> >>
> >> I don't see any other solution than keeping a database of NEED_XXX_R for
> >> each platform and then requiring these functions to show up before we
> >> declare a library to be thread-safe.  So far we're only dealing with
> >> three functions, to it should be doable.
> >
> > Right.  We can't assume because a *_r function is missing that the
> > normal function is thread-safe.
> So, given that UnixWare doesn't have gethostbyname_r and strerror_r, but 
> does have
> getpwuid_r, will y'all declare that UnixWare has thread-safety?
> 
> My vote is YES.

I am inclined to think yes.  It would prevent uglification of the code
by not having to special-case Unixware.

However, I was able to read the libc sources to confirm thread-safety. 
Because you can not see the source, would you try a threaded program and
see if calls to getpwuid from different threads return different
pointer values?

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

Tue, 2 Sep 2003 11:35:25 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)


--On Tuesday, September 02, 2003 11:35:25 -0400 Bruce Momjian 
<pgman@candle.pha.pa.us> wrote:

> Larry Rosenman wrote:
>>
>>
>> --On Tuesday, September 02, 2003 11:20:14 -0400 Bruce Momjian
>> <pgman@candle.pha.pa.us> wrote:
>>
>> > Peter Eisentraut wrote:
>> >> Lee Kindness writes:
>> >>
>> >> > You don't... and you simply shouldn't care. If there is a_r version
>> >> > available then we should use it - even if the plain version is
>> >> > "safe".
>> >>
>> >> The problem with this is that the automatic determination (in
>> >> configure) whether there is a xxx_r()  version is, in general,
>> >> fragile.  We cannot rely on configure saying that xxx_r() doesn't
>> >> exist, so the plain xxx() should be good enough.  Else, we'd be
>> >> shipping claimed-to-be-thread-safe libraries that might trigger bugs
>> >> that will be hard to track down.
>> >>
>> >> I don't see any other solution than keeping a database of NEED_XXX_R
>> >> for each platform and then requiring these functions to show up
>> >> before we declare a library to be thread-safe.  So far we're only
>> >> dealing with three functions, to it should be doable.
>> >
>> > Right.  We can't assume because a *_r function is missing that the
>> > normal function is thread-safe.
>> So, given that UnixWare doesn't have gethostbyname_r and strerror_r, but
>> does have
>> getpwuid_r, will y'all declare that UnixWare has thread-safety?
>>
>> My vote is YES.
>
> I am inclined to think yes.  It would prevent uglification of the code
> by not having to special-case Unixware.
>
> However, I was able to read the libc sources to confirm thread-safety.
> Because you can not see the source, would you try a threaded program and
> see if calls to getpwuid from different threads return different
> pointer values?
It won't prove anything on MY box, as it is a UNIPROCESSOR, so the threads 
won't be dispatched at the same time.

It's ok to assume thread-safety, as the SCO developer (Kean Johnston) asked 
the threads guys, and he said that the libc stuff is thread-safe so they 
don't have to have 2 different versions in libc.

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


Tue, 02 Sep 2003 10:37:45 -0500
Larry Rosenman <ler@lerctr.org>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
Bruce Momjian writes:
 > Right.  We can't assume because a *_r function is missing that the
 > normal function is thread-safe.

I recon i'll get blue in the face before long, and one of you guys
will fly over to Scotland to give me a good kicking!... But'll say it
again anyway...

That's not our concern - if the OS isn't thread safe we can't do
anything about it, and to worry about it is an enormous waste of
development time.

Who do you think is interested in a thread-safe libpq on a
non-thread-safe OS?

L.

Tue, 2 Sep 2003 18:29:25 +0100
Lee Kindness <lkindness@csl.co.uk>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
Bruce Momjian writes:
 > Lee Kindness wrote:
 > > No, it's not. Using the _r functions on such systems is BETTER because
 > > the API is clean and the function can be implmented in a reentrant and
 > > thread-safe fashion wuithout the need for thread local storage or
 > > mutex locking.
 > I don't care about overhead at this point.  These functions are rarely
 > called.

Nor do I, but there is no requirement or point in using the
traditional interface over the _r one then the traditional one is
known to be thread-safe. It only adds additional complexity.

L.

Tue, 2 Sep 2003 18:32:47 +0100
Lee Kindness <lkindness@csl.co.uk>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
Lee Kindness writes:

> Bruce Momjian writes:
>  > Right.  We can't assume because a *_r function is missing that the
>  > normal function is thread-safe.

> That's not our concern - if the OS isn't thread safe we can't do
> anything about it, and to worry about it is an enormous waste of
> development time.

There is a long way between configure not finding a particular *_r
function and the entire operating system not being thread-safe.  There are
many uncertainties along that way, and I believe my point was that the
only way we can get a degree of certainty about the result of a particular
build is that we keep a database of exactly what is required for
thread-safety on each platform.

-- 
Peter Eisentraut   peter_e@gmx.net


Tue, 2 Sep 2003 19:53:38 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)


--On Tuesday, September 02, 2003 19:53:38 +0200 Peter Eisentraut 
<peter_e@gmx.net> wrote:

> Lee Kindness writes:
>
>> Bruce Momjian writes:
>>  > Right.  We can't assume because a *_r function is missing that the
>>  > normal function is thread-safe.
>
>> That's not our concern - if the OS isn't thread safe we can't do
>> anything about it, and to worry about it is an enormous waste of
>> development time.
>
> There is a long way between configure not finding a particular *_r
> function and the entire operating system not being thread-safe.  There are
> many uncertainties along that way, and I believe my point was that the
> only way we can get a degree of certainty about the result of a particular
> build is that we keep a database of exactly what is required for
> thread-safety on each platform.
Ok, now, is my statement from a SCO Developer good enough to get 
thread-safety enabled
on UnixWare with only the getpwuid_r() function?

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


Tue, 02 Sep 2003 12:55:32 -0500
Larry Rosenman <ler@lerctr.org>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
Lee Kindness wrote:
> Bruce Momjian writes:
>  > Lee Kindness wrote:
>  > > No, it's not. Using the _r functions on such systems is BETTER because
>  > > the API is clean and the function can be implmented in a reentrant and
>  > > thread-safe fashion wuithout the need for thread local storage or
>  > > mutex locking.
>  > I don't care about overhead at this point.  These functions are rarely
>  > called.
> 
> Nor do I, but there is no requirement or point in using the
> traditional interface over the _r one then the traditional one is
> known to be thread-safe. It only adds additional complexity.

I am working on a patch that will _prefer_ the *_r functions, but only
fail if not found when the OS is marked as requiring them.  At this
point, the only OS so marked is Linux and Unixware (though my patch will
change Unixware to not requiring *_r).

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

Tue, 2 Sep 2003 17:35:51 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
Larry Rosenman wrote:
> 
> 
> --On Tuesday, September 02, 2003 19:53:38 +0200 Peter Eisentraut 
> <peter_e@gmx.net> wrote:
> 
> > Lee Kindness writes:
> >
> >> Bruce Momjian writes:
> >>  > Right.  We can't assume because a *_r function is missing that the
> >>  > normal function is thread-safe.
> >
> >> That's not our concern - if the OS isn't thread safe we can't do
> >> anything about it, and to worry about it is an enormous waste of
> >> development time.
> >
> > There is a long way between configure not finding a particular *_r
> > function and the entire operating system not being thread-safe.  There are
> > many uncertainties along that way, and I believe my point was that the
> > only way we can get a degree of certainty about the result of a particular
> > build is that we keep a database of exactly what is required for
> > thread-safety on each platform.
> Ok, now, is my statement from a SCO Developer good enough to get 
> thread-safety enabled
> on UnixWare with only the getpwuid_r() function?

Woh, I thought we just agreed that getpwuid_r() isn't required for
thread-safety on your platform.

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

Tue, 2 Sep 2003 18:12:48 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)


--On Tuesday, September 02, 2003 18:12:48 -0400 Bruce Momjian 
<pgman@candle.pha.pa.us> wrote:

> Larry Rosenman wrote:
>>
>>
>> --On Tuesday, September 02, 2003 19:53:38 +0200 Peter Eisentraut
>> <peter_e@gmx.net> wrote:
>>
>> > Lee Kindness writes:
>> >
>> >> Bruce Momjian writes:
>> >>  > Right.  We can't assume because a *_r function is missing that the
>> >>  > normal function is thread-safe.
>> >
>> >> That's not our concern - if the OS isn't thread safe we can't do
>> >> anything about it, and to worry about it is an enormous waste of
>> >> development time.
>> >
>> > There is a long way between configure not finding a particular *_r
>> > function and the entire operating system not being thread-safe.  There
>> > are many uncertainties along that way, and I believe my point was that
>> > the only way we can get a degree of certainty about the result of a
>> > particular build is that we keep a database of exactly what is
>> > required for thread-safety on each platform.
>> Ok, now, is my statement from a SCO Developer good enough to get
>> thread-safety enabled
>> on UnixWare with only the getpwuid_r() function?
>
> Woh, I thought we just agreed that getpwuid_r() isn't required for
> thread-safety on your platform.
it's CLEANER to use it.

Our API Signature is the _r version, why not use it when it's available?




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


Tue, 02 Sep 2003 17:13:59 -0500
Larry Rosenman <ler@lerctr.org>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
Larry Rosenman wrote:
> >> >> Bruce Momjian writes:
> >> >>  > Right.  We can't assume because a *_r function is missing that the
> >> >>  > normal function is thread-safe.
> >> >
> >> >> That's not our concern - if the OS isn't thread safe we can't do
> >> >> anything about it, and to worry about it is an enormous waste of
> >> >> development time.
> >> >
> >> > There is a long way between configure not finding a particular *_r
> >> > function and the entire operating system not being thread-safe.  There
> >> > are many uncertainties along that way, and I believe my point was that
> >> > the only way we can get a degree of certainty about the result of a
> >> > particular build is that we keep a database of exactly what is
> >> > required for thread-safety on each platform.
> >> Ok, now, is my statement from a SCO Developer good enough to get
> >> thread-safety enabled
> >> on UnixWare with only the getpwuid_r() function?
> >
> > Woh, I thought we just agreed that getpwuid_r() isn't required for
> > thread-safety on your platform.
> it's CLEANER to use it.
> 
> Our API Signature is the _r version, why not use it when it's available?

My new patch will optionally use it if it exists, but we still need to
know if it is required so if we don't find it, we throw an error.

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

Tue, 2 Sep 2003 18:32:03 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)


--On Tuesday, September 02, 2003 18:32:03 -0400 Bruce Momjian 
<pgman@candle.pha.pa.us> wrote:

> Larry Rosenman wrote:
>> >> >> Bruce Momjian writes:
>> >> >>  > Right.  We can't assume because a *_r function is missing that
>> >> >>  > the normal function is thread-safe.
>> >> >
>> >> >> That's not our concern - if the OS isn't thread safe we can't do
>> >> >> anything about it, and to worry about it is an enormous waste of
>> >> >> development time.
>> >> >
>> >> > There is a long way between configure not finding a particular *_r
>> >> > function and the entire operating system not being thread-safe.
>> >> > There are many uncertainties along that way, and I believe my point
>> >> > was that the only way we can get a degree of certainty about the
>> >> > result of a particular build is that we keep a database of exactly
>> >> > what is required for thread-safety on each platform.
>> >> Ok, now, is my statement from a SCO Developer good enough to get
>> >> thread-safety enabled
>> >> on UnixWare with only the getpwuid_r() function?
>> >
>> > Woh, I thought we just agreed that getpwuid_r() isn't required for
>> > thread-safety on your platform.
>> it's CLEANER to use it.
>>
>> Our API Signature is the _r version, why not use it when it's available?
>
> My new patch will optionally use it if it exists, but we still need to
> know if it is required so if we don't find it, we throw an error.

On UnixWare, either should be thread-safe, to the best of my knowledge. 
HOWEVER,
UnixWare has the getpwuid_r version, and since our API(from thread.c) is 
the _r signature,
we should just return getpwuid_r(...,....,..., etc).

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


Tue, 02 Sep 2003 17:33:50 -0500
Larry Rosenman <ler@lerctr.org>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
Larry Rosenman wrote:

>
>
> --On Tuesday, September 02, 2003 11:35:25 -0400 Bruce Momjian 
> <pgman@candle.pha.pa.us> wrote:
>
>> Larry Rosenman wrote:
>>
>>>
>>>
>>> --On Tuesday, September 02, 2003 11:20:14 -0400 Bruce Momjian
>>> <pgman@candle.pha.pa.us> wrote:
>>>
>>> > Peter Eisentraut wrote:
>>> >> Lee Kindness writes:
>>> >>
>>> >> > You don't... and you simply shouldn't care. If there is a_r 
>>> version
>>> >> > available then we should use it - even if the plain version is
>>> >> > "safe".
>>> >>
>>> >> The problem with this is that the automatic determination (in
>>> >> configure) whether there is a xxx_r()  version is, in general,
>>> >> fragile.  We cannot rely on configure saying that xxx_r() doesn't
>>> >> exist, so the plain xxx() should be good enough.  Else, we'd be
>>> >> shipping claimed-to-be-thread-safe libraries that might trigger bugs
>>> >> that will be hard to track down.
>>> >>
>>> >> I don't see any other solution than keeping a database of NEED_XXX_R
>>> >> for each platform and then requiring these functions to show up
>>> >> before we declare a library to be thread-safe.  So far we're only
>>> >> dealing with three functions, to it should be doable.
>>> >
>>> > Right.  We can't assume because a *_r function is missing that the
>>> > normal function is thread-safe.
>>> So, given that UnixWare doesn't have gethostbyname_r and strerror_r, 
>>> but
>>> does have
>>> getpwuid_r, will y'all declare that UnixWare has thread-safety?
>>>
>>> My vote is YES.
>>
>>
>> I am inclined to think yes.  It would prevent uglification of the code
>> by not having to special-case Unixware.
>>
>> However, I was able to read the libc sources to confirm thread-safety.
>> Because you can not see the source, would you try a threaded program and
>> see if calls to getpwuid from different threads return different
>> pointer values?
>
> It won't prove anything on MY box, as it is a UNIPROCESSOR, so the 
> threads won't be dispatched at the same time.

I have 2 bi-pro machines here both running unixware 7.1.3 I can make 
tests if you want

>
> It's ok to assume thread-safety, as the SCO developer (Kean Johnston) 
> asked the threads guys, and he said that the libc stuff is thread-safe 
> so they don't have to have 2 different versions in libc.
>
> LER
>
>
>


Wed, 03 Sep 2003 16:28:45 +0200
Olivier PRENANT <ohp@pyrenet.fr>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
Olivier PRENANT wrote:

> Larry Rosenman wrote:
>
>>
>>
>>> <SNIP>
>>> I am inclined to think yes.  It would prevent uglification of the code
>>> by not having to special-case Unixware.
>>>
>>> However, I was able to read the libc sources to confirm thread-safety.
>>> Because you can not see the source, would you try a threaded program 
>>> and
>>> see if calls to getpwuid from different threads return different
>>> pointer values?
>>
>>
>> It won't prove anything on MY box, as it is a UNIPROCESSOR, so the 
>> threads won't be dispatched at the same time.
>
>
> I have 2 bi-pro machines here both running unixware 7.1.3 I can make 
> tests if you want
>
>>
>> It's ok to assume thread-safety, as the SCO developer (Kean Johnston) 
>> asked the threads guys, and he said that the libc stuff is 
>> thread-safe so they don't have to have 2 different versions in libc.
>>
>> LER
>>
>>
>>
>
If any one can write a program that can prove anything (I can't), I'm 
willing to test it here on a bi-pro (bi PIII and bi-XEON with JT 
enabled) running uw713.
Maybe it will end the discussion and make a point in either way. So that 
we (you?) can move on with the other unixware patches.


Wed, 03 Sep 2003 19:33:24 +0200
Olivier PRENANT <ohp@pyrenet.fr>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
Olivier PRENANT wrote:
> >> It's ok to assume thread-safety, as the SCO developer (Kean Johnston) 
> >> asked the threads guys, and he said that the libc stuff is 
> >> thread-safe so they don't have to have 2 different versions in libc.
> >>
> >> LER
> >>
> >>
> >>
> >
> If any one can write a program that can prove anything (I can't), I'm 
> willing to test it here on a bi-pro (bi PIII and bi-XEON with JT 
> enabled) running uw713.
> Maybe it will end the discussion and make a point in either way. So that 
> we (you?) can move on with the other unixware patches.

You don't need a SMP machine to test threads.  You just need one thread
to do the function call, then another to do the function call and see if
the two pointers are different.  They calls don't have to happen at the
same time.  Ideally you could make call in the two threads with
different arguments, then after both calls are completed, test that the
two static areas have the proper _different_ values.

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

Wed, 3 Sep 2003 13:58:53 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
Larry Rosenman wrote:
> >> > Woh, I thought we just agreed that getpwuid_r() isn't required for
> >> > thread-safety on your platform.
> >> it's CLEANER to use it.
> >>
> >> Our API Signature is the _r version, why not use it when it's available?
> >
> > My new patch will optionally use it if it exists, but we still need to
> > know if it is required so if we don't find it, we throw an error.
> 
> On UnixWare, either should be thread-safe, to the best of my knowledge. 
> HOWEVER,
> UnixWare has the getpwuid_r version, and since our API(from thread.c) is 
> the _r signature,
> we should just return getpwuid_r(...,....,..., etc).

OK, I have marked Unixware as not requiring *_r functions.  I decided
against optionally using the *_r functions if they exist because it
requires more tests/defines in configure.in, the standard changed the
arguments for some *_r functions over time (from drafts), and there is
no advantage if the libc versions are thread-safe already.

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

Wed, 3 Sep 2003 14:00:55 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
Ok, I don't know much about threads; would you write a simple program for
us to test?
On Wed, 3 Sep 2003, Bruce Momjian wrote:

> Date: Wed, 3 Sep 2003 13:58:53 -0400 (EDT)
> From: Bruce Momjian <pgman@candle.pha.pa.us>
> To: Olivier PRENANT <ohp@pyrenet.fr>
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Unixware Patch (Was: Re: Beta2 Tag'd and Bundled
>     ...)
>
> Olivier PRENANT wrote:
> > >> It's ok to assume thread-safety, as the SCO developer (Kean Johnston)
> > >> asked the threads guys, and he said that the libc stuff is
> > >> thread-safe so they don't have to have 2 different versions in libc.
> > >>
> > >> LER
> > >>
> > >>
> > >>
> > >
> > If any one can write a program that can prove anything (I can't), I'm
> > willing to test it here on a bi-pro (bi PIII and bi-XEON with JT
> > enabled) running uw713.
> > Maybe it will end the discussion and make a point in either way. So that
> > we (you?) can move on with the other unixware patches.
>
> You don't need a SMP machine to test threads.  You just need one thread
> to do the function call, then another to do the function call and see if
> the two pointers are different.  They calls don't have to happen at the
> same time.  Ideally you could make call in the two threads with
> different arguments, then after both calls are completed, test that the
> two static areas have the proper _different_ values.
>
>

-- 
Olivier PRENANT        	        Tel: +33-5-61-50-97-00 (Work)
6, Chemin d'Harraud Turrou           +33-5-61-50-97-01 (Fax)
31190 AUTERIVE                       +33-6-07-63-80-64 (GSM)
FRANCE                          Email: ohp@pyrenet.fr
------------------------------------------------------------------------------
Make your life a dream, make your dream a reality. (St Exupery)

Wed, 3 Sep 2003 20:03:03 +0200 (MET DST)
ohp@pyrenet.fr
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)


--On Wednesday, September 03, 2003 14:00:55 -0400 Bruce Momjian 
<pgman@candle.pha.pa.us> wrote:

> Larry Rosenman wrote:
>> >> > Woh, I thought we just agreed that getpwuid_r() isn't required for
>> >> > thread-safety on your platform.
>> >> it's CLEANER to use it.
>> >>
>> >> Our API Signature is the _r version, why not use it when it's
>> >> available?
>> >
>> > My new patch will optionally use it if it exists, but we still need to
>> > know if it is required so if we don't find it, we throw an error.
>>
>> On UnixWare, either should be thread-safe, to the best of my knowledge.
>> HOWEVER,
>> UnixWare has the getpwuid_r version, and since our API(from thread.c) is
>> the _r signature,
>> we should just return getpwuid_r(...,....,..., etc).
>
> OK, I have marked Unixware as not requiring *_r functions.  I decided
> against optionally using the *_r functions if they exist because it
> requires more tests/defines in configure.in, the standard changed the
> arguments for some *_r functions over time (from drafts), and there is
> no advantage if the libc versions are thread-safe already.
Ok, I guess I can live with this, but our API from the rest of libpq to 
thread.c is
the getpwuid_r() api.

I would think it would make more sense to use it if it's available.

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


Wed, 03 Sep 2003 13:03:27 -0500
Larry Rosenman <ler@lerctr.org>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
ohp@pyrenet.fr wrote:
> > Olivier PRENANT wrote:
> > > >> It's ok to assume thread-safety, as the SCO developer (Kean Johnston)
> > > >> asked the threads guys, and he said that the libc stuff is
> > > >> thread-safe so they don't have to have 2 different versions in libc.
> > > >
> > > If any one can write a program that can prove anything (I can't), I'm
> > > willing to test it here on a bi-pro (bi PIII and bi-XEON with JT
> > > enabled) running uw713.
> > > Maybe it will end the discussion and make a point in either way. So that
> > > we (you?) can move on with the other unixware patches.
> >
> > You don't need a SMP machine to test threads.  You just need one thread
> > to do the function call, then another to do the function call and see if
> > the two pointers are different.  They calls don't have to happen at the
> > same time.  Ideally you could make call in the two threads with
> > different arguments, then after both calls are completed, test that the
> > two static areas have the proper _different_ values.
> >
> >
> Ok, I don't know much about threads; would you write a simple program for
> us to test?

OK, done, and attached.  It is also now in CVS as
src/tools/test_thread_funcs.c.

In hindsight, I should have done this long ago.  However, it only tests
the thread-safety of functions.  It does not completely test your threading
capability.

I would like every operating system that supports thread-safety to run
this program and report back the results.

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

/*-------------------------------------------------------------------------
 *
 * test_thread_funcs.c
 *      libc thread test program
 *
 * Portions Copyright (c) 1996-2003, PostgreSQL Global Development Group
 * Portions Copyright (c) 1994, Regents of the University of California
 *
 *	$Header: /cvsroot/pgsql-server/src/tools/test_thread_funcs.c,v 1.2 2003/09/03 19:36:31 momjian Exp $
 *
 *	This program tests to see if your standard libc functions use
 *	pthread_setspecific()/pthread_getspecific() to be thread-safe.
 *	See src/port/thread.c for more details.
 *
 *	This program first tests to see if each function returns a constant
 *	memory pointer within the same thread, then, assuming it does, tests
 *	to see if the pointers are different for different threads.  If they
 *	are, the function is thread-safe.
 *
 *	This program must be compiled with the thread flags required by your
 *	operating system.  See src/template for the appropriate flags, if any.
 *
 *-------------------------------------------------------------------------
 */


#include <pthread.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <netdb.h>
#include <sys/types.h>
#include <pwd.h>
#include <string.h>
#include <errno.h>

void func_call_1(void);
void func_call_2(void);

struct hostent *hostent_p1;
struct hostent *hostent_p2;

struct passwd *passwd_p1;
struct passwd *passwd_p2;

char *strerror_p1;
char *strerror_p2;

int main(int argc, char *argv[])
{
	pthread_t		thread1,
					thread2;

	if (argc > 1)
	{
			fprintf(stderr, "Usage: %s\n", argv[0]);
			return 1;
	}

	pthread_create(&thread1, NULL, (void *) func_call_1, NULL);
	pthread_create(&thread2, NULL, (void *) func_call_2, NULL);
	pthread_join(thread1, NULL);
	pthread_join(thread2, NULL);

	if (hostent_p1 == hostent_p2)
		printf("Your gethostbyname() is _not_ thread-safe\n");
	if (passwd_p1 == passwd_p2)
		printf("Your getpwuid() is _not_ thread-safe\n");
	if (strerror_p1 == strerror_p2)
		printf("Your strerror() is _not_ thread-safe\n");

	if (hostent_p1 != hostent_p2 &&
		passwd_p1 != passwd_p2 &&
		strerror_p1 != strerror_p2)
		printf("Your functions are all thread-safe\n");
	else
		printf("Your functions are _not_ all thread-safe\n");

	return 0;
}

void func_call_1(void) {
	void *p;

	hostent_p1 = gethostbyname("yahoo.com");
	p = gethostbyname("slashdot.org");
	if (hostent_p1 != p)
	{
		printf("Your gethostbyname() changes the static memory area between calls\n");
		hostent_p1 = NULL;	/* force thread-safe failure report */
	}

	passwd_p1 = getpwuid(0);
	p = getpwuid(1);
	if (passwd_p1 != p)
	{
		printf("Your getpwuid() changes the static memory area between calls\n");
		passwd_p1 = NULL;	/* force thread-safe failure report */
	}

	strerror_p1 = strerror(EACCES);
	/*
	 *	If strerror() uses sys_errlist, the pointer might change for different
	 *	errno values, so we don't check to see if it varies within the thread.
	 */
}


void func_call_2(void) {
	void *p;

	hostent_p2 = gethostbyname("google.com");
	p = gethostbyname("postgresql.org");
	if (hostent_p2 != p)
	{
		printf("Your gethostbyname() changes the static memory area between calls\n");
		hostent_p2 = NULL;	/* force thread-safe failure report */
	}

	passwd_p2 = getpwuid(2);
	p = getpwuid(3);
	if (passwd_p2 != p)
	{
		printf("Your getpwuid() changes the static memory area between calls\n");
		passwd_p2 = NULL;	/* force thread-safe failure report */
	}

	strerror_p2 = strerror(EINVAL);
	/*
	 *	If strerror() uses sys_errlist, the pointer might change for different
	 *	errno values, so we don't check to see if it varies within the thread.
	 */
}
Wed, 3 Sep 2003 15:36:53 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
>From UnixWare:

$ cc -O -Kpthread test_thread.c -o test_thread -lsocket -lnsl
UX:acomp: WARNING: "test_thread.c", line 60: argument #3 incompatible with 
prototype: pthread_create()
UX:acomp: WARNING: "test_thread.c", line 61: argument #3 incompatible with 
prototype: pthread_create()
$ ./test_thread
Your functions are all thread-safe
$

--On Wednesday, September 03, 2003 15:36:53 -0400 Bruce Momjian 
<pgman@candle.pha.pa.us> wrote:

> ohp@pyrenet.fr wrote:
>> > Olivier PRENANT wrote:
>> > > >> It's ok to assume thread-safety, as the SCO developer (Kean
>> > > >> Johnston) asked the threads guys, and he said that the libc stuff
>> > > >> is thread-safe so they don't have to have 2 different versions in
>> > > >> libc.
>> > > >
>> > > If any one can write a program that can prove anything (I can't), I'm
>> > > willing to test it here on a bi-pro (bi PIII and bi-XEON with JT
>> > > enabled) running uw713.
>> > > Maybe it will end the discussion and make a point in either way. So
>> > > that we (you?) can move on with the other unixware patches.
>> >
>> > You don't need a SMP machine to test threads.  You just need one thread
>> > to do the function call, then another to do the function call and see
>> > if the two pointers are different.  They calls don't have to happen at
>> > the same time.  Ideally you could make call in the two threads with
>> > different arguments, then after both calls are completed, test that the
>> > two static areas have the proper _different_ values.
>> >
>> >
>> Ok, I don't know much about threads; would you write a simple program for
>> us to test?
>
> OK, done, and attached.  It is also now in CVS as
> src/tools/test_thread_funcs.c.
>
> In hindsight, I should have done this long ago.  However, it only tests
> the thread-safety of functions.  It does not completely test your
> threading capability.
>
> I would like every operating system that supports thread-safety to run
> this program and report back the results.



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


Wed, 03 Sep 2003 14:53:39 -0500
Larry Rosenman <ler@lerctr.org>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
FWIW, I do confirm, on dual XEON with JT enabled
On Wed, 3 Sep 2003, Larry Rosenman wrote:

> Date: Wed, 03 Sep 2003 14:53:39 -0500
> From: Larry Rosenman <ler@lerctr.org>
> To: Bruce Momjian <pgman@candle.pha.pa.us>, ohp@pyrenet.fr
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Unixware Patch (Was: Re: Beta2 Tag'd and Bundled
>     ...)
>
> >From UnixWare:
>
> $ cc -O -Kpthread test_thread.c -o test_thread -lsocket -lnsl
> UX:acomp: WARNING: "test_thread.c", line 60: argument #3 incompatible with
> prototype: pthread_create()
> UX:acomp: WARNING: "test_thread.c", line 61: argument #3 incompatible with
> prototype: pthread_create()
> $ ./test_thread
> Your functions are all thread-safe
> $
>
> --On Wednesday, September 03, 2003 15:36:53 -0400 Bruce Momjian
> <pgman@candle.pha.pa.us> wrote:
>
> > ohp@pyrenet.fr wrote:
> >> > Olivier PRENANT wrote:
> >> > > >> It's ok to assume thread-safety, as the SCO developer (Kean
> >> > > >> Johnston) asked the threads guys, and he said that the libc stuff
> >> > > >> is thread-safe so they don't have to have 2 different versions in
> >> > > >> libc.
> >> > > >
> >> > > If any one can write a program that can prove anything (I can't), I'm
> >> > > willing to test it here on a bi-pro (bi PIII and bi-XEON with JT
> >> > > enabled) running uw713.
> >> > > Maybe it will end the discussion and make a point in either way. So
> >> > > that we (you?) can move on with the other unixware patches.
> >> >
> >> > You don't need a SMP machine to test threads.  You just need one thread
> >> > to do the function call, then another to do the function call and see
> >> > if the two pointers are different.  They calls don't have to happen at
> >> > the same time.  Ideally you could make call in the two threads with
> >> > different arguments, then after both calls are completed, test that the
> >> > two static areas have the proper _different_ values.
> >> >
> >> >
> >> Ok, I don't know much about threads; would you write a simple program for
> >> us to test?
> >
> > OK, done, and attached.  It is also now in CVS as
> > src/tools/test_thread_funcs.c.
> >
> > In hindsight, I should have done this long ago.  However, it only tests
> > the thread-safety of functions.  It does not completely test your
> > threading capability.
> >
> > I would like every operating system that supports thread-safety to run
> > this program and report back the results.
>
>
>
>

-- 
Olivier PRENANT        	        Tel: +33-5-61-50-97-00 (Work)
6, Chemin d'Harraud Turrou           +33-5-61-50-97-01 (Fax)
31190 AUTERIVE                       +33-6-07-63-80-64 (GSM)
FRANCE                          Email: ohp@pyrenet.fr
------------------------------------------------------------------------------
Make your life a dream, make your dream a reality. (St Exupery)

Wed, 3 Sep 2003 22:05:33 +0200 (MET DST)
ohp@pyrenet.fr
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
Larry Rosenman wrote:
> >From UnixWare:
> 
> $ cc -O -Kpthread test_thread.c -o test_thread -lsocket -lnsl
> UX:acomp: WARNING: "test_thread.c", line 60: argument #3 incompatible with 
> prototype: pthread_create()
> UX:acomp: WARNING: "test_thread.c", line 61: argument #3 incompatible with 
> prototype: pthread_create()
> $ ./test_thread
> Your functions are all thread-safe
> $

Well, that's great news, and so clear too!

I am curious about the compiler warnings.

What does your OS want for the 3rd argument of pthread_create()?  I
thought a void pointer would be OK for everyone:

    pthread_create(&thread1, NULL, (void *) func_call_1, NULL);

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

Wed, 3 Sep 2003 16:51:51 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
ohp@pyrenet.fr wrote:
> FWIW, I do confirm, on dual XEON with JT enabled

Operating system?

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

Wed, 3 Sep 2003 16:52:31 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
ohp@pyrenet.fr wrote:
> FWIW, I do confirm, on dual XEON with JT enabled

Oh, I now see OS as Unixware:

> I have 2 bi-pro machines here both running unixware
> 7.1.3 I can make tests if you want


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

Wed, 3 Sep 2003 16:54:24 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)


--On Wednesday, September 03, 2003 16:51:51 -0400 Bruce Momjian 
<pgman@candle.pha.pa.us> wrote:

> Larry Rosenman wrote:
>> > From UnixWare:
>>
>> $ cc -O -Kpthread test_thread.c -o test_thread -lsocket -lnsl
>> UX:acomp: WARNING: "test_thread.c", line 60: argument #3 incompatible
>> with  prototype: pthread_create()
>> UX:acomp: WARNING: "test_thread.c", line 61: argument #3 incompatible
>> with  prototype: pthread_create()
>> $ ./test_thread
>> Your functions are all thread-safe
>> $
>
> Well, that's great news, and so clear too!
>
> I am curious about the compiler warnings.
>
> What does your OS want for the 3rd argument of pthread_create()?  I
> thought a void pointer would be OK for everyone:
>
>     pthread_create(&thread1, NULL, (void *) func_call_1, NULL);

 void *(*start_routine)(void*)

Here is our man page:
http://lerami.lerctr.org:8458/en/man/html.3pthread/pthread_create.3pthread.
html

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


Wed, 03 Sep 2003 15:56:27 -0500
Larry Rosenman <ler@lerctr.org>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
Larry Rosenman wrote:
> 
> 
> --On Wednesday, September 03, 2003 16:51:51 -0400 Bruce Momjian 
> <pgman@candle.pha.pa.us> wrote:
> 
> > Larry Rosenman wrote:
> >> > From UnixWare:
> >>
> >> $ cc -O -Kpthread test_thread.c -o test_thread -lsocket -lnsl
> >> UX:acomp: WARNING: "test_thread.c", line 60: argument #3 incompatible
> >> with  prototype: pthread_create()
> >> UX:acomp: WARNING: "test_thread.c", line 61: argument #3 incompatible
> >> with  prototype: pthread_create()
> >> $ ./test_thread
> >> Your functions are all thread-safe
> >> $
> >
> > Well, that's great news, and so clear too!
> >
> > I am curious about the compiler warnings.
> >
> > What does your OS want for the 3rd argument of pthread_create()?  I
> > thought a void pointer would be OK for everyone:
> >
> >     pthread_create(&thread1, NULL, (void *) func_call_1, NULL);
> 
>  void *(*start_routine)(void*)
> 
> Here is our man page:
> http://lerami.lerctr.org:8458/en/man/html.3pthread/pthread_create.3pthread.
> html

Yes, that's what I have too.  What if you have the functions taking
(void *) rather than void.  Does that make the warnings disappear?

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

Wed, 3 Sep 2003 17:09:49 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
On Wed, Sep 03, 2003 at 03:36:53PM -0400, Bruce Momjian wrote:
> 
> I would like every operating system that supports thread-safety to run
> this program and report back the results.

On a Linux system with glibc 2.1:
Your gethostbyname() is _not_ thread-safe
Your getpwuid() is _not_ thread-safe
Your functions are _not_ all thread-safe


 From a Linux system with libc5:
Your gethostbyname() is _not_ thread-safe
Your getpwuid() is _not_ thread-safe
Your functions are _not_ all thread-safe


Kurt


Wed, 3 Sep 2003 23:20:40 +0200
Kurt Roeckx <Q@ping.be>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
--On Wednesday, September 03, 2003 17:09:49 -0400 Bruce Momjian 
<pgman@candle.pha.pa.us> wrote:

> Larry Rosenman wrote:
>>
>>
>> --On Wednesday, September 03, 2003 16:51:51 -0400 Bruce Momjian
>> <pgman@candle.pha.pa.us> wrote:
>>
>> > Larry Rosenman wrote:
>> >> > From UnixWare:
>> >>
>> >> $ cc -O -Kpthread test_thread.c -o test_thread -lsocket -lnsl
>> >> UX:acomp: WARNING: "test_thread.c", line 60: argument #3 incompatible
>> >> with  prototype: pthread_create()
>> >> UX:acomp: WARNING: "test_thread.c", line 61: argument #3 incompatible
>> >> with  prototype: pthread_create()
>> >> $ ./test_thread
>> >> Your functions are all thread-safe
>> >> $
>> >
>> > Well, that's great news, and so clear too!
>> >
>> > I am curious about the compiler warnings.
>> >
>> > What does your OS want for the 3rd argument of pthread_create()?  I
>> > thought a void pointer would be OK for everyone:
>> >
>> >     pthread_create(&thread1, NULL, (void *) func_call_1, NULL);
>>
>>  void *(*start_routine)(void*)
>>
>> Here is our man page:
>> http://lerami.lerctr.org:8458/en/man/html.3pthread/pthread_create.3pthre
>> ad. html
>
> Yes, that's what I have too.  What if you have the functions taking
> (void *) rather than void.  Does that make the warnings disappear?

$ r cc
cc -O -Kpthread test_thread.c -o test_thread -lsocket -lnsl
$ ./test_thread
Your functions are all thread-safe
$

Attached is my modified version.



-- 
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
Wed, 03 Sep 2003 16:23:20 -0500
Larry Rosenman <ler@lerctr.org>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
Kurt Roeckx wrote:
> On Wed, Sep 03, 2003 at 03:36:53PM -0400, Bruce Momjian wrote:
> > 
> > I would like every operating system that supports thread-safety to run
> > this program and report back the results.
> 
> On a Linux system with glibc 2.1:
> Your gethostbyname() is _not_ thread-safe
> Your getpwuid() is _not_ thread-safe
> Your functions are _not_ all thread-safe
> 
> 
> >From a Linux system with libc5:
> Your gethostbyname() is _not_ thread-safe
> Your getpwuid() is _not_ thread-safe
> Your functions are _not_ all thread-safe

Thanks.

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

Wed, 3 Sep 2003 18:07:47 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
Larry Rosenman wrote:
> >> > What does your OS want for the 3rd argument of pthread_create()?  I
> >> > thought a void pointer would be OK for everyone:
> >> >
> >> >     pthread_create(&thread1, NULL, (void *) func_call_1, NULL);
> >>
> >>  void *(*start_routine)(void*)
> >>
> >> Here is our man page:
> >> http://lerami.lerctr.org:8458/en/man/html.3pthread/pthread_create.3pthre
> >> ad. html
> >
> > Yes, that's what I have too.  What if you have the functions taking
> > (void *) rather than void.  Does that make the warnings disappear?
> 
> $ r cc
> cc -O -Kpthread test_thread.c -o test_thread -lsocket -lnsl
> $ ./test_thread
> Your functions are all thread-safe
> $

I have updated the code to tighten the cast:

    pthread_create(&thread1, NULL, (void * (*)(void *)) func_call_1, NULL);
    pthread_create(&thread2, NULL, (void * (*)(void *)) func_call_2, NULL);

The change is in CVS.  Does that fix it?

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

Wed, 3 Sep 2003 18:35:44 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
Can you pass me what's in CVS (anon hasn't updated afaict).

And, what didn't you like about my version?

LER


--On Wednesday, September 03, 2003 18:35:44 -0400 Bruce Momjian 
<pgman@candle.pha.pa.us> wrote:

> Larry Rosenman wrote:
>> >> > What does your OS want for the 3rd argument of pthread_create()?  I
>> >> > thought a void pointer would be OK for everyone:
>> >> >
>> >> >     pthread_create(&thread1, NULL, (void *) func_call_1, NULL);
>> >>
>> >>  void *(*start_routine)(void*)
>> >>
>> >> Here is our man page:
>> >> http://lerami.lerctr.org:8458/en/man/html.3pthread/pthread_create.3pt
>> >> hre ad. html
>> >
>> > Yes, that's what I have too.  What if you have the functions taking
>> > (void *) rather than void.  Does that make the warnings disappear?
>>
>> $ r cc
>> cc -O -Kpthread test_thread.c -o test_thread -lsocket -lnsl
>> $ ./test_thread
>> Your functions are all thread-safe
>> $
>
> I have updated the code to tighten the cast:
>
>     pthread_create(&thread1, NULL, (void * (*)(void *)) func_call_1,
> NULL);     pthread_create(&thread2, NULL, (void * (*)(void *))
> func_call_2, NULL);
>
> The change is in CVS.  Does that fix it?



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


Wed, 03 Sep 2003 18:59:17 -0500
Larry Rosenman <ler@lerctr.org>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
FreeBSD 4.8/i386:

Your gethostbyname() is _not_ thread-safe
Your getpwuid() is _not_ thread-safe
Your functions are _not_ all thread-safe

Chris

----- Original Message ----- 
From: "Bruce Momjian" <pgman@candle.pha.pa.us>
To: "Kurt Roeckx" <Q@ping.be>
Cc: <pgsql-hackers@postgresql.org>
Sent: Thursday, September 04, 2003 6:07 AM
Subject: Re: [HACKERS] Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)


> Kurt Roeckx wrote:
> > On Wed, Sep 03, 2003 at 03:36:53PM -0400, Bruce Momjian wrote:
> > >
> > > I would like every operating system that supports thread-safety to run
> > > this program and report back the results.
> >
> > On a Linux system with glibc 2.1:
> > Your gethostbyname() is _not_ thread-safe
> > Your getpwuid() is _not_ thread-safe
> > Your functions are _not_ all thread-safe
> >
> >
> > >From a Linux system with libc5:
> > Your gethostbyname() is _not_ thread-safe
> > Your getpwuid() is _not_ thread-safe
> > Your functions are _not_ all thread-safe
>
> Thanks.
>
> -- 
>   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
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>


Mon, 8 Sep 2003 12:23:06 +0800
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
FreeBSD/i386 thread test
Christopher Kings-Lynne wrote:
> FreeBSD 4.8/i386:
> 
> Your gethostbyname() is _not_ thread-safe
> Your getpwuid() is _not_ thread-safe
> Your functions are _not_ all thread-safe

Interesting.  Do you have all the *_r files listed in thread.c?  I sure
hope so.  I assume you used the template thread compile flags for this
test.

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

Mon, 8 Sep 2003 00:25:50 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: FreeBSD/i386 thread test
-On [20030908 06:32], Bruce Momjian (pgman@candle.pha.pa.us) wrote:
>> Your gethostbyname() is _not_ thread-safe
>> Your getpwuid() is _not_ thread-safe
>> Your functions are _not_ all thread-safe
>
>Interesting.  Do you have all the *_r files listed in thread.c?  I sure
>hope so.  I assume you used the template thread compile flags for this
>test.

Both gethostbyname() and getpwuid() have no _r equivalents on
FreeBSD-STABLE, ergo no thread-safe functions of these.

-- 
Jeroen Ruigrok van der Werven <asmodai(at)wxs.nl> / asmodai
PGP fingerprint: 2D92 980E 45FE 2C28 9DB7  9D88 97E6 839B 2EAC 625B
http://www.tendra.org/   | http://www.in-nomine.org/~asmodai/diary/
Gravitation can not be held responsible for people falling in love...

Mon, 8 Sep 2003 07:52:39 +0200
Jeroen Ruigrok/asmodai <asmodai@wxs.nl>
Re: FreeBSD/i386 thread test
Jeroen Ruigrok/asmodai wrote:
> -On [20030908 06:32], Bruce Momjian (pgman@candle.pha.pa.us) wrote:
> >> Your gethostbyname() is _not_ thread-safe
> >> Your getpwuid() is _not_ thread-safe
> >> Your functions are _not_ all thread-safe
> >
> >Interesting.  Do you have all the *_r files listed in thread.c?  I sure
> >hope so.  I assume you used the template thread compile flags for this
> >test.
> 
> Both gethostbyname() and getpwuid() have no _r equivalents on
> FreeBSD-STABLE, ergo no thread-safe functions of these.

So you don't have all the *_r functions, and your non-*_r functions
aren't thread-safe.  Should we disable theading on FreeBSD?  Seems so.

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

Mon, 8 Sep 2003 12:50:18 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: FreeBSD/i386 thread test
--On Monday, September 08, 2003 12:50:18 -0400 Bruce Momjian 
<pgman@candle.pha.pa.us> wrote:

> Jeroen Ruigrok/asmodai wrote:
>> -On [20030908 06:32], Bruce Momjian (pgman@candle.pha.pa.us) wrote:
>> >> Your gethostbyname() is _not_ thread-safe
>> >> Your getpwuid() is _not_ thread-safe
>> >> Your functions are _not_ all thread-safe
>> >
>> > Interesting.  Do you have all the *_r files listed in thread.c?  I sure
>> > hope so.  I assume you used the template thread compile flags for this
>> > test.
>>
>> Both gethostbyname() and getpwuid() have no _r equivalents on
>> FreeBSD-STABLE, ergo no thread-safe functions of these.
>
> So you don't have all the *_r functions, and your non-*_r functions
> aren't thread-safe.  Should we disable theading on FreeBSD?  Seems so.

Same is true on 5.1-CURRENT:
$ uname -a
FreeBSD lerlaptop-red.iadfw.net 5.1-CURRENT FreeBSD 5.1-CURRENT #51: Mon 
Sep  8 05:52:15 CDT 2003 
ler@lerlaptop.lerctr.org:/usr/obj/usr/src/sys/LERLAPTOP  i386
$ ls -l test_t*
-rwxr-xr-x  1 ler  ler  6689 Sep  3 16:40 test_thread
-rw-------  1 ler  ler  3611 Sep  3 16:22 test_thread.c
-rw-------  1 ler  ler  3638 Sep  3 19:01 test_thread2.c
$ cc -O -o test_thread2 test_thread2.c -lc_r
$ ./test_thread2
Your gethostbyname() is _not_ thread-safe
Your getpwuid() is _not_ thread-safe
Your functions are _not_ all thread-safe
$ man -k gethostbyname_r
gethostbyname_r: nothing appropriate
$ man -k getpwuid
getpwent(3), getpwent_r(3), getpwnam(3), getpwnam_r(3), getpwuid(3), 
getpwuid_r(
3), setpassent(3), setpwent(3), endpwent(3) - password database operations
$

-- 
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
Mon, 08 Sep 2003 12:07:27 -0500
Larry Rosenman <ler@lerctr.org>
Re: FreeBSD/i386 thread test
-On [20030908 18:52], Bruce Momjian (pgman@candle.pha.pa.us) wrote:
>So you don't have all the *_r functions, and your non-*_r functions
>aren't thread-safe.  Should we disable theading on FreeBSD?  Seems so.

Exactly.  Most other threading works though. :)

-- 
Jeroen Ruigrok van der Werven <asmodai(at)wxs.nl> / asmodai
PGP fingerprint: 2D92 980E 45FE 2C28 9DB7  9D88 97E6 839B 2EAC 625B
http://www.tendra.org/   | http://www.in-nomine.org/~asmodai/diary/
The only source of knowledge is experience...

Mon, 8 Sep 2003 19:25:42 +0200
Jeroen Ruigrok/asmodai <asmodai@wxs.nl>
Re: FreeBSD/i386 thread test
Bruce Momjian writes:

> > Both gethostbyname() and getpwuid() have no _r equivalents on
> > FreeBSD-STABLE, ergo no thread-safe functions of these.
>
> So you don't have all the *_r functions, and your non-*_r functions
> aren't thread-safe.  Should we disable theading on FreeBSD?  Seems so.

Why would FreeBSD have a "library of thread-safe libc functions" (libc_r)
if the functions weren't thread-safe?  I think the test is faulty.

-- 
Peter Eisentraut   peter_e@gmx.net


Mon, 8 Sep 2003 23:53:12 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: FreeBSD/i386 thread test
-On [20030908 23:52], Peter Eisentraut (peter_e@gmx.net) wrote:
>Why would FreeBSD have a "library of thread-safe libc functions" (libc_r)
>if the functions weren't thread-safe?  I think the test is faulty.

Having libc_r is not a guarantee that all functions of libc are
represented in that library as thread-safe functions.

gethostbyname_r() is a notable reentrant function which is absent in
FreeBSD.

-- 
Jeroen Ruigrok van der Werven <asmodai(at)wxs.nl> / asmodai
PGP fingerprint: 2D92 980E 45FE 2C28 9DB7  9D88 97E6 839B 2EAC 625B
http://www.tendra.org/   | http://www.in-nomine.org/~asmodai/diary/
Character is what you are in the dark...

Mon, 8 Sep 2003 23:55:11 +0200
Jeroen Ruigrok/asmodai <asmodai@wxs.nl>
Re: FreeBSD/i386 thread test
Jeroen Ruigrok/asmodai wrote:

>-On [20030908 23:52], Peter Eisentraut (peter_e@gmx.net) wrote:
>  
>
>>Why would FreeBSD have a "library of thread-safe libc functions" (libc_r)
>>if the functions weren't thread-safe?  I think the test is faulty.
>>    
>>
A thread-safe library has a per-thread errno value (i.e. errno is a 
#define to a function call), thread-safe io buffers for stdio, etc. Some 
of these changes cause a noticable overhead, thus a seperate library for 
those users who want to avoid that overhead.

Reentrancy is independant from _r: If you look at the prototype of 
gethostbyname(), it's just not possible to make that thread safe with 
reasonable effort - the C library would have to keep one buffer per 
thread around.

>Having libc_r is not a guarantee that all functions of libc are
>represented in that library as thread-safe functions.
>
>gethostbyname_r() is a notable reentrant function which is absent in
>FreeBSD.
>  
>
Is there a thread-safe alternate to gethostbyname() for FreeBSD?

--
    Manfred



Tue, 09 Sep 2003 00:17:53 +0200
Manfred Spraul <manfred@colorfullife.com>
Re: FreeBSD/i386 thread test
Manfred Spraul wrote:
> Jeroen Ruigrok/asmodai wrote:
> 
> >-On [20030908 23:52], Peter Eisentraut (peter_e@gmx.net) wrote:
> >  
> >
> >>Why would FreeBSD have a "library of thread-safe libc functions" (libc_r)
> >>if the functions weren't thread-safe?  I think the test is faulty.
> >>    
> >>
> A thread-safe library has a per-thread errno value (i.e. errno is a 
> #define to a function call), thread-safe io buffers for stdio, etc. Some 
> of these changes cause a noticable overhead, thus a seperate library for 
> those users who want to avoid that overhead.
> 
> Reentrancy is independant from _r: If you look at the prototype of 
> gethostbyname(), it's just not possible to make that thread safe with 
> reasonable effort - the C library would have to keep one buffer per 
> thread around.

See the top of src/port/thread.c --- that's exactly what is does (keep
one buffer per thread around).

 *  Threading sometimes requires specially-named versions of functions
 *  that return data in static buffers, like strerror_r() instead of
 *  strerror().  Other operating systems use pthread_setspecific()
 *  and pthread_getspecific() internally to allow standard library
 *  functions to return static data to threaded applications.

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

Mon, 8 Sep 2003 18:33:25 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: FreeBSD/i386 thread test
Bruce Momjian wrote:
> Manfred Spraul wrote:
> > Jeroen Ruigrok/asmodai wrote:
> > 
> > >-On [20030908 23:52], Peter Eisentraut (peter_e@gmx.net) wrote:
> > >  
> > >
> > >>Why would FreeBSD have a "library of thread-safe libc functions" (libc_r)
> > >>if the functions weren't thread-safe?  I think the test is faulty.
> > >>    
> > >>
> > A thread-safe library has a per-thread errno value (i.e. errno is a 
> > #define to a function call), thread-safe io buffers for stdio, etc. Some 
> > of these changes cause a noticable overhead, thus a seperate library for 
> > those users who want to avoid that overhead.
> > 
> > Reentrancy is independant from _r: If you look at the prototype of 
> > gethostbyname(), it's just not possible to make that thread safe with 
> > reasonable effort - the C library would have to keep one buffer per 
> > thread around.
> 
> See the top of src/port/thread.c --- that's exactly what is does (keep
> one buffer per thread around).
> 
>  *  Threading sometimes requires specially-named versions of functions
>  *  that return data in static buffers, like strerror_r() instead of
>  *  strerror().  Other operating systems use pthread_setspecific()
>  *  and pthread_getspecific() internally to allow standard library
>  *  functions to return static data to threaded applications.

And that's exactly what src/tools/test_thread_funcs.c tests for.
-- 
  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

Mon, 8 Sep 2003 18:36:07 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: FreeBSD/i386 thread test
On Thu, 4 Sep 2003 05:36 am, Bruce Momjian wrote:
> I would like every operating system that supports thread-safety to run
> this program and report back the results.

Okay, here's results from the machines I have access to... I think what you're 
going to find is that an awful lot of platforms that do support pthreads do 
not necessarily provide thread-safe libc functions. 

Is it possible to identify which functions are likely to be called by multiple 
threads and create our own mutex-wrapper functions for them? Disabling 
thread-safety seems pretty drastic simply because of a lack of getpwuid_r() 
or thread-safe getpwuid(). Or do I misunderstand your concerns?

Regards, Philip.

$ uname -a
OSF1 hostname V4.0 1229 alpha
$ ./a.out 
Your getpwuid() changes the static memory area between calls
Your strerror() is _not_ thread-safe
Your functions are _not_ all thread-safe

There are older _r functions, but they're deprecated as the non _r are now 
thread-safe.

$ uname -a
SunOS hostname 5.6 Generic_105181-05 sun4m sparc SUNW,SPARCstation-4
$ gcc -lpthread -lnsl test.c # this works
$ ./a.out
Your gethostbyname() is _not_ thread-safe
Your getpwuid() is _not_ thread-safe
Your functions are _not_ all thread-safe

getpwduid_r provided
gethostbyname_r not provided

FreeBSD 5.1 (i386)
$ cc -pthread test.c
$ ./a.out
Your gethostbyname() is _not_ thread-safe
Your getpwuid() is _not_ thread-safe
Your functions are _not_ all thread-safe

manpage notes "BUGS
     These functions use static data storage; if the data is needed for future
     use, it should be copied before any subsequent calls overwrite it."

FreeBSD 4.8 (i386)
$ cc -pthread test.c
$ ./a.out
Your gethostbyname() is _not_ thread-safe
Your getpwuid() is _not_ thread-safe
Your functions are _not_ all thread-safe

manpage notes "BUGS
     These functions use static data storage; if the data is needed for future
     use, it should be copied before any subsequent calls overwrite it."

Linux 2.4.18-3 (i686)
$ ./a.out
Your gethostbyname() is _not_ thread-safe
Your getpwuid() is _not_ thread-safe
Your functions are _not_ all thread-safe

manpage notes "The  functions  gethostbyname()  and gethostbyaddr() may return 
pointers to static data, which may be over-
       written by later calls. Copying the struct hostent does not suffice, 
since it contains pointers  -  a  deep
       copy is required.

Glibc2 also has reentrant versions gethostbyname_r() and gethostbyname2_r().  
These return 0 on success and
       nonzero  on  error.  The  result of the call is now stored in the 
struct with address ret.  After the call,
       *result will be NULL on error or point to the result on success.  
Auxiliary data is stored  in  the  buffer
       buf  of  length buflen.  (If the buffer is too small, these functions 
will return ERANGE.)  No global vari-
       able h_errno is modified, but the address of a variable in which  to  
store  error  numbers  is  passed  in
       h_errnop."

Wed, 10 Sep 2003 10:38:04 +1000
Philip Yarra <philip@utiba.com>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
Philip Yarra wrote:
> On Thu, 4 Sep 2003 05:36 am, Bruce Momjian wrote:
> > I would like every operating system that supports thread-safety to run
> > this program and report back the results.
> 
> Okay, here's results from the machines I have access to... I think what you're 
> going to find is that an awful lot of platforms that do support pthreads do 
> not necessarily provide thread-safe libc functions. 

I see --- looks bad ---- failures below for OSF, Solaris, and FreeBSD
below.

> Is it possible to identify which functions are likely to be called by multiple 
> threads and create our own mutex-wrapper functions for them? Disabling 
> thread-safety seems pretty drastic simply because of a lack of getpwuid_r() 
> or thread-safe getpwuid(). Or do I misunderstand your concerns?

I am starting to think your approach is the only way to go --- I was
thinking of it for FreeBSD, but now, with these additional platforms, it
seems almost a requirement.

We would have to get some thread mutex, make the function call, copy the
return values into the passed pointer, and release the mutex?  Do we
test to see if we are in thread mode before doing the locking?  Is that
test even possible or desirable?

Seems we will need to rename the config variable to be
NON_REENTRANT_FUNC_NAMES_THREADSAFE, and add configure checks for each
*_r function, and fall back to the mutex if both settings are false.

This part has me concerned too:

> Copying the struct hostent does not suffice, since it contains
> pointers  -  a  deep copy is required.

Would someone with thread mutex experience assist me?


---------------------------------------------------------------------------

> 
> Regards, Philip.
> 
> $ uname -a
> OSF1 hostname V4.0 1229 alpha
> $ ./a.out 
> Your getpwuid() changes the static memory area between calls
> Your strerror() is _not_ thread-safe
> Your functions are _not_ all thread-safe
> 
> There are older _r functions, but they're deprecated as the non _r are now 
> thread-safe.
> 
> $ uname -a
> SunOS hostname 5.6 Generic_105181-05 sun4m sparc SUNW,SPARCstation-4
> $ gcc -lpthread -lnsl test.c # this works
> $ ./a.out
> Your gethostbyname() is _not_ thread-safe
> Your getpwuid() is _not_ thread-safe
> Your functions are _not_ all thread-safe
> 
> getpwduid_r provided
> gethostbyname_r not provided
> 
> FreeBSD 5.1 (i386)
> $ cc -pthread test.c
> $ ./a.out
> Your gethostbyname() is _not_ thread-safe
> Your getpwuid() is _not_ thread-safe
> Your functions are _not_ all thread-safe
> 
> manpage notes "BUGS
>      These functions use static data storage; if the data is needed for future
>      use, it should be copied before any subsequent calls overwrite it."
> 
> FreeBSD 4.8 (i386)
> $ cc -pthread test.c
> $ ./a.out
> Your gethostbyname() is _not_ thread-safe
> Your getpwuid() is _not_ thread-safe
> Your functions are _not_ all thread-safe
> 
> manpage notes "BUGS
>      These functions use static data storage; if the data is needed for future
>      use, it should be copied before any subsequent calls overwrite it."
> 
> Linux 2.4.18-3 (i686)
> $ ./a.out
> Your gethostbyname() is _not_ thread-safe
> Your getpwuid() is _not_ thread-safe
> Your functions are _not_ all thread-safe
> 
> manpage notes "The  functions  gethostbyname()  and gethostbyaddr() may return 
> pointers to static data, which may be over-
>        written by later calls. Copying the struct hostent does not suffice, 
> since it contains pointers  -  a  deep
>        copy is required.
> 
> Glibc2 also has reentrant versions gethostbyname_r() and gethostbyname2_r().  
> These return 0 on success and
>        nonzero  on  error.  The  result of the call is now stored in the 
> struct with address ret.  After the call,
>        *result will be NULL on error or point to the result on success.  
> Auxiliary data is stored  in  the  buffer
>        buf  of  length buflen.  (If the buffer is too small, these functions 
> will return ERANGE.)  No global vari-
>        able h_errno is modified, but the address of a variable in which  to  
> store  error  numbers  is  passed  in
>        h_errnop."
> 

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

Tue, 9 Sep 2003 21:46:35 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
On Wed, 10 Sep 2003 11:46 am, Bruce Momjian wrote:
> I see --- looks bad ---- failures below for OSF, Solaris, and FreeBSD
> below.

Actually, I am not sure the OSF failure is correctly reported... your test app 
had me a little baffled in that case.

> We would have to get some thread mutex, make the function call, copy the
> return values into the passed pointer, and release the mutex?  Do we
> test to see if we are in thread mode before doing the locking?  Is that
> test even possible or desirable?

I guess as with the threading stuff in ECPG:

#ifdef SOME_DEF (sorry, have to check the ECPG source on that one)
pthread_mutex_lock(&my_mutex)
#endif

/* do stuff */

#ifdef SOME_DEF 
pthread_mutex_unlock(&my_mutex)
#endif

> Seems we will need to rename the config variable to be
> NON_REENTRANT_FUNC_NAMES_THREADSAFE, and add configure checks for each
> *_r function, and fall back to the mutex if both settings are false.

Yeah, or you could just always use the wrapper and not try to do all the test 
in configure... doubtless less efficient, but maybe better for the mental 
health...

> This part has me concerned too:
> > Copying the struct hostent does not suffice, since it contains
> > pointers  -  a  deep copy is required.
>
> Would someone with thread mutex experience assist me?

Ummm... replace /* do stuff /* above with a deep copy of the hostent struct. 
I'll give that a shot if you like.

Regards, Philip.

Wed, 10 Sep 2003 12:07:42 +1000
Philip Yarra <philip@utiba.com>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
Philip Yarra wrote:
> On Wed, 10 Sep 2003 11:46 am, Bruce Momjian wrote:
> > I see --- looks bad ---- failures below for OSF, Solaris, and FreeBSD
> > below.
> 
> Actually, I am not sure the OSF failure is correctly reported... your test app 
> had me a little baffled in that case.

Baffler is my middle name.  ;-)

Anyway, the output was:

	$ uname -a
	OSF1 hostname V4.0 1229 alpha
	$ ./a.out
	Your getpwuid() changes the static memory area between calls
	Your strerror() is _not_ thread-safe
	Your functions are _not_ all thread-safe

What that says is that getpwuid doesn't return the same pointer value
for two calls even in the same thread.  C comments say:

 *  This program first tests to see if each function returns a constant
 *  memory pointer within the same thread, then, assuming it does, tests
 *  to see if the pointers are different for different threads.  If they
 *  are, the function is thread-safe.

So my guess is that OSF returns a pointer into a pre-allocated area that
it allocates for every user in the database, or at least on every call
to a username --- perhaps it creates a hash in libc indexed by username
--- anyway, it is probably threadsafe, but strerror isn't, so we are
dead anyway.  :-)

> > We would have to get some thread mutex, make the function call, copy the
> > return values into the passed pointer, and release the mutex?  Do we
> > test to see if we are in thread mode before doing the locking?  Is that
> > test even possible or desirable?
> 
> I guess as with the threading stuff in ECPG:
> 
> #ifdef SOME_DEF (sorry, have to check the ECPG source on that one)
> pthread_mutex_lock(&my_mutex)
> #endif
> 
> /* do stuff */
> 
> #ifdef SOME_DEF 
> pthread_mutex_unlock(&my_mutex)
> #endif

Yep.  Ugly but required.

> > Seems we will need to rename the config variable to be
> > NON_REENTRANT_FUNC_NAMES_THREADSAFE, and add configure checks for each
> > *_r function, and fall back to the mutex if both settings are false.
> 
> Yeah, or you could just always use the wrapper and not try to do all the test 
> in configure... doubtless less efficient, but maybe better for the mental 
> health...

True.  In fact, on platforms with non-*_r functions that are
thread-safe, those locks are already done in libc anyway.  The problem
is that on platforms that don't have non *_r thread-safe, and don't
have all the *_r functions, we would be adding overhead to libpq that
isn't already part of libc on that platform, and that seems wrong to me.
We might have to produce a libpq_r and ecpg_r (yuck) on those platforms.

Double-yuck.

> > This part has me concerned too:
> > > Copying the struct hostent does not suffice, since it contains
> > > pointers  -  a  deep copy is required.
> >
> > Would someone with thread mutex experience assist me?
> 
> Ummm... replace /* do stuff /* above with a deep copy of the hostent struct. 
> I'll give that a shot if you like.

Tripple-yuck.  :-)

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

Tue, 9 Sep 2003 22:29:17 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
On Wed, 10 Sep 2003 12:29 pm, Bruce Momjian wrote:
> --- anyway, it is probably threadsafe, but strerror isn't, so we are
> dead anyway.  :-)

Oh, I see. Yep, good point. Strange that strerror isn't threadsafe when 
everything else is... maybe Strange is OSF's middle name.

> > #ifdef SOME_DEF (sorry, have to check the ECPG source on that one)
> > pthread_mutex_lock(&my_mutex)
> > #endif
> >
> > /* do stuff */
> >
> > #ifdef SOME_DEF
> > pthread_mutex_unlock(&my_mutex)
> > #endif
>
> Yep.  Ugly but required.

Could be worse - at least creating a wrapper function keeps the 
aesthetically-offensive code away from most of the code, and everyone else 
could just call pg_gethostbyname() or whatever...

> > Yeah, or you could just always use the wrapper and not try to do all the
> > test in configure... doubtless less efficient, but maybe better for the
> > mental health...
>
> True.  In fact, on platforms with non-*_r functions that are
> thread-safe, those locks are already done in libc anyway.  The problem
> is that on platforms that don't have non *_r thread-safe, and don't
> have all the *_r functions, we would be adding overhead to libpq that
> isn't already part of libc on that platform, and that seems wrong to me.

> Double-yuck.

No, correct me if I'm wrong, but the #ifdef'd code is removed by the 
pre-processor, so platforms without thread support would gain only the 
overhead of a single function call? That doesn't seem so steep. 

The actual copying of the structs wouldn't be needed in this case, so handle 
that like:

#ifdef SOME_DEF
/* copy structure and set return pointer to this copy /*
#else
/* set return pointer to global buffer */
#endif

It's only a penalty for platforms with thread-safe functions called within the 
mutex_locked section... and if we're talking about functions like 
gethostbyname() (which may well be making a network call to a DNS server) I 
doubt the second mutex_lock would be a noticeable penalty.

Making copies of structures is some penalty, that's true... I might try some 
timings to see how much of a penalty. Are these functions likely to see such 
heavy use that the additional times are a problem?

> We might have to produce a libpq_r and ecpg_r (yuck) on those platforms.

I beg you, stay away from this idea! Informix does this, and it isn't pretty. 
I have the core files to prove it.

> > Ummm... replace /* do stuff /* above with a deep copy of the hostent
> > struct. I'll give that a shot if you like.
>
> Tripple-yuck.  :-)

Hey, are you impugning my coding style? If so, you'll have to join the queue. 
:-)

Do you want me to have a try at the gethostbyname() wrappers, or is it going 
to be a waste of time?

Regards, Philip.

Wed, 10 Sep 2003 13:01:50 +1000
Philip Yarra <philip@utiba.com>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tripple-yuck.  :-)

It doesn't seem to me that we should take on the job of providing
thread-safe implementations of basic libc functions.  If a particular
OS cannot manage to offer that functionality, then we should mark it
not-thread-safe and move on.  Persons unhappy with this labeling must
take it up with their OS developers, not us.

			regards, tom lane

Wed, 10 Sep 2003 00:11:08 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...) 
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Tripple-yuck.  :-)
> 
> It doesn't seem to me that we should take on the job of providing
> thread-safe implementations of basic libc functions.  If a particular
> OS cannot manage to offer that functionality, then we should mark it
> not-thread-safe and move on.  Persons unhappy with this labeling must
> take it up with their OS developers, not us.

Yep, that is one clear option.  It would certainly make my job easier.

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

Wed, 10 Sep 2003 00:12:22 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Tripple-yuck.  :-)
> 
> It doesn't seem to me that we should take on the job of providing
> thread-safe implementations of basic libc functions.  If a particular
> OS cannot manage to offer that functionality, then we should mark it
> not-thread-safe and move on.  Persons unhappy with this labeling must
> take it up with their OS developers, not us.

We do actually have a way to report OS thread failure to the user --- if
they ask for --enable-thread-safety, we just throw an error.

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

Wed, 10 Sep 2003 00:15:17 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
On Wed, 10 Sep 2003 02:15 pm, Bruce Momjian wrote:
> Tom Lane wrote:
> > It doesn't seem to me that we should take on the job of providing
> > thread-safe implementations of basic libc functions.  If a particular
> > OS cannot manage to offer that functionality, then we should mark it
> > not-thread-safe and move on.  

This would be a pretty short list unless I count wrong! This excludes all 
releases of FreeBSD (and I'm willing to bet other BSDs), Solaris (at least 
the old version I have), OSF, Linux, and who knows what else? MacOS X?

> > Persons unhappy with this labeling must
> > take it up with their OS developers, not us.

Surely the development of PostgreSQL has seen lots of platform shortcomings 
found and worked-around? Why not this as well?

Are these non-threadsafe functions really going to be so heavily-used that we 
can't live with the wrappers? I mean, AFAIK these threading issues are only 
in ECPG and libpq - it's not like re-writing the backend code is required.

Wed, 10 Sep 2003 14:25:07 +1000
Philip Yarra <philip@utiba.com>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
Philip Yarra <philip@utiba.com> writes:
> On Wed, 10 Sep 2003 02:15 pm, Bruce Momjian wrote:
>> Tom Lane wrote:
>>> It doesn't seem to me that we should take on the job of providing
>>> thread-safe implementations of basic libc functions.  If a particular
>>> OS cannot manage to offer that functionality, then we should mark it
>>> not-thread-safe and move on.  

> This would be a pretty short list unless I count wrong!

If it's a short list, then it's a short list.

> Surely the development of PostgreSQL has seen lots of platform shortcomings 
> found and worked-around? Why not this as well?

Because we are not working in a vacuum.  A thread-safe implementation of
libpq is of zero value to an application unless it also has thread-safe
implementations of the other libraries it depends on.  When the
platform's libc has more thread-safety holes than the average block of
swiss cheese, there is no reason that I can see for us to expend effort
on workarounds that only fix libpq's usage.  Any app that might want to
use libpq is going to hit those same bugs, and so in the long run the
only useful answer is for the platform to fix its libc.

The real bottom line here is: who is going to try to build threaded
apps on platforms with un-thread-safe libc?  And why should we be the
ones to try to save them from suffering the pain they deserve?  We have
enough problems of our own to deal with...

			regards, tom lane

Wed, 10 Sep 2003 00:39:05 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...) 

Philip Yarra <philip@utiba.com> writes:

> On Wed, 10 Sep 2003 02:15 pm, Bruce Momjian wrote:
>
> This would be a pretty short list unless I count wrong! This excludes all 
> releases of FreeBSD (and I'm willing to bet other BSDs), Solaris (at least 
> the old version I have), OSF, Linux, and who knows what else? MacOS X?

Uhm I stopped reading this thread a while back. Linux has all the reentrant
functions required like strerror_r, getpwnam_r, etc. Why do we think it
wouldn't pass?


> Are these non-threadsafe functions really going to be so heavily-used that we 
> can't live with the wrappers? I mean, AFAIK these threading issues are only 
> in ECPG and libpq - it's not like re-writing the backend code is required.

It's only libpq and ECPG where thread-safety is at all an issue.

-- 
greg


10 Sep 2003 14:05:16 -0400
Greg Stark <gsstark@mit.edu>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
Tom wrote: 
> At this point it should move to pghackers, I think.
(responding to a patch for ISO 8601 "Time Intervals" in pgsql-patches)

Looks like I'll take a shot at more broadly hacking the postgresql 
time interval code.  Before doing so, I wanted to ask opinions
regarding what the "right" behavior is of various timestamp/interval
operations.

I think the best way ask the specific questions is to ask a 
quiz highlighting some of the unexpected behavior with the 
current implementation.

 1. What should this expression give:

    select '0.01 years'::interval > '0.01 months'::interval;

    A) False    - the first is 0 months, the second is about 25000 seconds.
    B) True     - one is about 300000 seconds, the other is about 25000.
    C) An error - fractional dates are asking for trouble.
    D) Something else -- please tell me.

 2. If I have this expression:

       select '2003-01-31'::timestamp + '2 months',
              '2003-01-31'::timestamp + '1 month' + '1 month'
              '2003-01-31'::timestamp + '0.5 months'::interval * 4;

    would I expect the results to:

    A) All be different.
       The first is  89 days, (Mar 31, because it's the last day of Mar).
       the second    86 days, (Mar 28, because February clips the date)
       and the third 90 days  (Apr 01, because half-months are 15 days).
    B) All should be the same.
       Two months is two months no matter how you slice it.
    C) An error - with fractional months being undefined.
    D) Something else -- please tell me.

 3. Or odd behavior with time-zones.

       select '2002-01-01'::timestamp + '6 months',
              '2002-01-01'::timestamp + '181 days',
              '2002-01-01'::timestamp + '4344 hours';

    Note that those months have 181 days, and 4344 is 
    181 days * 24 hours. I would expect:

    A) The first one represents midnight on 2002-07-01.
       The second two one hour different (1AM) to make up 
       for the missed hour on daylight savings.

    B) The first two expressions (Days and Months) are both 
       "calendar time" so they'd both be midnight. 
       Only the third one would be 1AM.

    D) Something else -- please tell me.


To give away the answers...

  (A) Appears to be current behavior.
  (B) Is one possible proposal that started being discussed on PGPatches.
  (C) Is one other possible proposal that mentioned on PGPatches.
  (D) Would be appreciated.

I'd love to hear what any specs, especially the SQL spec
has to say for it.

    Ron


Wed, 10 Sep 2003 11:48:58 -0700
"Ron Mayer" <ron@intervideo.com>
Broken(?) 'interval' problems. [Was: ISO 8601 "Time Intervals"]
On Wed, Sep 10, 2003 at 11:48:58 -0700,
  Ron Mayer <ron@intervideo.com> wrote:
> 
> Looks like I'll take a shot at more broadly hacking the postgresql 
> time interval code.  Before doing so, I wanted to ask opinions
> regarding what the "right" behavior is of various timestamp/interval
> operations.

Can you document which part of a mixed interval (with both months and
seconds parts) gets added first to a timestamp? I haven't ever run
accross anything which says which gets done first.

Wed, 10 Sep 2003 15:21:44 -0500
Bruno Wolff III <bruno@wolff.to>
Re: Broken(?) 'interval' problems. [Was: ISO 8601 "Time Intervals"]
Bruno wrote:
> 
> Can you document which part of a mixed interval (with both months and
> seconds parts) gets added first to a timestamp? I haven't ever run
> across anything which says which gets done first.
> 

In the existing code, the sql spec, or the proposed implementation?

In the existing code, I think everything with "+" gets done
in in the same order (left-to-right?), regardless of if the
fields are timestamps or intervals.

This leads to cool crazy behavior like getting different
answers for this:

  logs=# select '.5 months'::interval + 
                '.5 months'::interval + 
                '2003-01-01'::timestamp;
        ?column?
  ---------------------
   2003-01-01 00:00:00
  (1 row)
  
  logs=# select '2003-01-01'::timestamp + 
                '.5 months'::interval +
                '.5 months'::interval;
          ?column?
  ------------------------ 
   2003-01-31 00:00:00-08
  (1 row)

With addition not being commutative, all sorts of pain can result.
The thing I'm proposing, is to define a form of time-math
that is as consistant as possible.

There are at least two reasonable ways of doing this -- using 
calendar time, or using absolute time.  

ISO 8601 makes such distinctions between "day" which it
defines as 24 hours, and "calendar day" which it defines 
as 24 hours +/- leap minutes and seconds.

The way this would work, we could:

  (1) Using calendar time:
      When doing math on 'intervals' and 'timestamps', we would keep 
      the fundementally different units separate until the end.
      This means keeping separate track of
         years & months  in units of months
         weeks & days    in units of days
         hours and less  in units of seconds
      through out the calculation.
      This means you could have an intervals of '.5 months' without
      it converting to 15 days until the very end.

  (2) Using absolute time:
      Interval math could take a odd shortcut of turning everything
      to seconds early in the calculation and converting back at
      the end.

I actually think each of the two are useful for different applications;
so I'm really tempted to create a GUC parameter
  date_math = 'absolute' or 'calendar'
to select between the two.


Wed, 10 Sep 2003 15:43:56 -0700
"Ron Mayer" <ron@intervideo.com>
Re: Broken(?) 'interval' problems. [Was: ISO 8601 "Time Intervals"]
On Wed, Sep 10, 2003 at 15:43:56 -0700,
  Ron Mayer <ron@intervideo.com> wrote:
> Bruno wrote:
> > 
> > Can you document which part of a mixed interval (with both months and
> > seconds parts) gets added first to a timestamp? I haven't ever run
> > across anything which says which gets done first.
> > 
> 
> In the existing code, the sql spec, or the proposed implementation?

In whatever is going to get implemented.

> In the existing code, I think everything with "+" gets done
> in in the same order (left-to-right?), regardless of if the
> fields are timestamps or intervals.

That isn't what I was asking about. An interval has two parts. One
part is the number of months in the interval and the other part is
the number of seconds (or perhaps milliseconds). Often a single interval
will only have one of these parts be nonzero. However if both parts are
nonzero it makes a difference in which part gets added first.
For example '2003-02-28'::date + '1 month 1 day'::interval might
be either 2003-03-29 or 2003-04-01. In 7.4 it is currently 2003-03-29,
but since it isn't documented it isn't clear if that will be true
in future versions.

Wed, 10 Sep 2003 19:21:19 -0500
Bruno Wolff III <bruno@wolff.to>
Re: Broken(?) 'interval' problems. [Was: ISO 8601 "Time Intervals"]
On Wed, 10 Sep 2003 02:39 pm, Tom Lane wrote:
> A thread-safe implementation of
> libpq is of zero value to an application unless it also has thread-safe
> implementations of the other libraries it depends on.  

Not necessarily so - we've managed okay so far (several years) working on 
platforms that don't fall into that short list. It can be done.

Thus far we have had to use Sybase or Informix because they do support 
thread-safe C interfaces.

> Any app that might want to
> use libpq is going to hit those same bugs, and so in the long run the
> only useful answer is for the platform to fix its libc.

The useful answer (so far) is to not use PostgreSQL for these applications, 
but to stick with a database that does support a threadsafe C interface. I 
think that's a pity.

I agree, it would make life easier if vendors supported threadsafe libc 
functions. 

> The real bottom line here is: who is going to try to build threaded
> apps on platforms with un-thread-safe libc?  

The company I work for. I got involved in this issue so we could port from 
Sybase and Informix to PostgreSQL. I assume there are other people out there 
who'd be interested as well.

> And why should we be the
> ones to try to save them from suffering the pain they deserve?  

1) Leave users to cope with their own code issues, but make sure the 
database's C interface isn't one of them. 
2) Because it's good enough for (Oracle|Informix|Sybase)

So moving forward: do we try Bruce's idea of libpq_r and ecpg_r? If people 
want to risk the overhead of wrapped libc calls, they can build the threaded 
lib versions and link against those. Would that be acceptable to people?

Regards, Philip.



Thu, 11 Sep 2003 10:56:20 +1000
Philip Yarra <philip@utiba.com>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)

Bruno wrote:
> ...An interval has two parts... the number of months...and...the number of 
> seconds...if both parts are nonzero it makes a difference in which part 
> gets added first. For example '2003-02-28'::date + '1 month 1 day'::interval
> might be either 2003-03-29 or 2003-04-01. In 7.4 it is currently 2003-03-29,

Ah.. I understand.

At least one other application that does date math, MSFT Excel
also claims 2003-03-29 when I use the expression 
 "=DATE(YEAR(B3),MONTH(B3)+1,DAY(B3)+1)"
so I think that's a reasonable rule to keep.

Anyone, please let me know if there are good reasons such as
standards or other major applications that behave otherwise.


Thanks for this other interesting case that I need to worry about!

And yes, I'll document it as well. :-)

   Ron

PS: I'm not receiving some emails I send to hackers. If you
    need a timely answer please cc me -- though I will follow
    the thread on archives as well to catch anything I miss.


Wed, 10 Sep 2003 18:15:43 -0700
"Ron Mayer" <ron@intervideo.com>
Re: Broken(?) 'interval' problems. [Was: ISO 8601 "Time Intervals"]
Hi,
after Beta1 I'd reported problems in the regression tests under Digital
Unix/Tru64. Unfortunately I had no time to report about my tests and to
check Beta2 before now.

Beta2 builds fine on Digital Unix 4.0G:

template1=# SELECT version();
                              version
-------------------------------------------------------------------
 PostgreSQL 7.4beta2 on alphaev67-dec-osf4.0g, compiled by cc -std

and regression tests are ok.

Under Beta1 the regression tests failed in random ways: I've run tens of
sets, with a number of errors ranging from 0 to 8-9. Almost any test
have failed once or more, and I could not recognise any apparent
pattern. I tend to put the blame on the test themselves rather that the
database, or maybe to the environment of the tests. 

-- 
Alessio F. Bragadini		alessio@albourne.com
APL Financial Services		http://village.albourne.com
Nicosia, Cyprus		 	phone: +357-22755750

"It is more complicated than you think"
		-- The Eighth Networking Truth from RFC 1925


Fri, 12 Sep 2003 17:45:27 +0300
Alessio Bragadini <alessio@albourne.com>
Re: Beta2 Tag'd and Bundled ...

I need someone running NetBSD to read the top of
src/tools/test_thread_funcs.c and compile and run that function and
report the results.

Thanks.

---------------------------------------------------------------------------

Christopher Kings-Lynne wrote:
> FreeBSD 4.8/i386:
> 
> Your gethostbyname() is _not_ thread-safe
> Your getpwuid() is _not_ thread-safe
> Your functions are _not_ all thread-safe
> 
> Chris
> 
> ----- Original Message ----- 
> From: "Bruce Momjian" <pgman@candle.pha.pa.us>
> To: "Kurt Roeckx" <Q@ping.be>
> Cc: <pgsql-hackers@postgresql.org>
> Sent: Thursday, September 04, 2003 6:07 AM
> Subject: Re: [HACKERS] Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
> 
> 
> > Kurt Roeckx wrote:
> > > On Wed, Sep 03, 2003 at 03:36:53PM -0400, Bruce Momjian wrote:
> > > >
> > > > I would like every operating system that supports thread-safety to run
> > > > this program and report back the results.
> > >
> > > On a Linux system with glibc 2.1:
> > > Your gethostbyname() is _not_ thread-safe
> > > Your getpwuid() is _not_ thread-safe
> > > Your functions are _not_ all thread-safe
> > >
> > >
> > > >From a Linux system with libc5:
> > > Your gethostbyname() is _not_ thread-safe
> > > Your getpwuid() is _not_ thread-safe
> > > Your functions are _not_ all thread-safe
> >
> > Thanks.
> >
> > -- 
> >   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
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 4: Don't 'kill -9' the postmaster
> >
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
> 

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

Fri, 12 Sep 2003 12:18:52 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Need NetBSD thread tester
--On Friday, September 12, 2003 12:18:52 -0400 Bruce Momjian 
<pgman@candle.pha.pa.us> wrote:

>
> I need someone running NetBSD to read the top of
> src/tools/test_thread_funcs.c and compile and run that function and
> report the results.
>
I have access to one NetBSD system on an Alpha:

$ uname -a
NetBSD milo.cirr.com 1.6.1_STABLE NetBSD 1.6.1_STABLE (MILO) #1: Sun Jun  1 
20:44:15 CDT 2003 
eric@milo.cirr.com:/rmt/.amd/egsner/root/work/eric/NetBSD-1.6/src/sys/arch/
alpha/compile/MILO alpha
$ cc -O -o test_thread_funcs test_thread_funcs.c
test_thread_funcs.c:27: pthread.h: No such file or directory
$ cc -O -pthread -o test_thread_funcs test_thread_funcs.c
cc: unrecognized option `-pthread'
test_thread_funcs.c:27: pthread.h: No such file or directory
$ cc -O -pthreads -o test_thread_funcs test_thread_funcs.c
cc: unrecognized option `-pthreads'
test_thread_funcs.c:27: pthread.h: No such file or directory
$ locate pthread.h
$
-- 
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
Fri, 12 Sep 2003 11:54:31 -0500
Larry Rosenman <ler@lerctr.org>
Re: Need NetBSD thread tester
Larry Rosenman wrote:
-- Start of PGP signed section.
> 
> 
> --On Friday, September 12, 2003 12:18:52 -0400 Bruce Momjian 
> <pgman@candle.pha.pa.us> wrote:
> 
> >
> > I need someone running NetBSD to read the top of
> > src/tools/test_thread_funcs.c and compile and run that function and
> > report the results.
> >
> I have access to one NetBSD system on an Alpha:
> 
> $ uname -a
> NetBSD milo.cirr.com 1.6.1_STABLE NetBSD 1.6.1_STABLE (MILO) #1: Sun Jun  1 
> 20:44:15 CDT 2003 
> eric@milo.cirr.com:/rmt/.amd/egsner/root/work/eric/NetBSD-1.6/src/sys/arch/
> alpha/compile/MILO alpha
> $ cc -O -o test_thread_funcs test_thread_funcs.c
> test_thread_funcs.c:27: pthread.h: No such file or directory
> $ cc -O -pthread -o test_thread_funcs test_thread_funcs.c
> cc: unrecognized option `-pthread'
> test_thread_funcs.c:27: pthread.h: No such file or directory
> $ cc -O -pthreads -o test_thread_funcs test_thread_funcs.c
> cc: unrecognized option `-pthreads'
> test_thread_funcs.c:27: pthread.h: No such file or directory
> $ locate pthread.h

Wow, that is strange.  Someone else told me NetBSD supports threads, and
doesn't need any special compile flags, but of course, it has to have
pthread.h to support threads.  NetBSD 1.6.1 is very current, so it isn't
an old OS.

Can you compile if you remove the pthread.h include?  No special compile
flags should be required.

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

Fri, 12 Sep 2003 13:03:33 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Need NetBSD thread tester
--On Friday, September 12, 2003 13:03:33 -0400 Bruce Momjian 
<pgman@candle.pha.pa.us> wrote:

> Larry Rosenman wrote:
> -- Start of PGP signed section.
>>
>>
>> --On Friday, September 12, 2003 12:18:52 -0400 Bruce Momjian
>> <pgman@candle.pha.pa.us> wrote:
>>
>> >
>> > I need someone running NetBSD to read the top of
>> > src/tools/test_thread_funcs.c and compile and run that function and
>> > report the results.
>> >
>> I have access to one NetBSD system on an Alpha:
>>
>> $ uname -a
>> NetBSD milo.cirr.com 1.6.1_STABLE NetBSD 1.6.1_STABLE (MILO) #1: Sun Jun
>> 1  20:44:15 CDT 2003
>> eric@milo.cirr.com:/rmt/.amd/egsner/root/work/eric/NetBSD-1.6/src/sys/ar
>> ch/ alpha/compile/MILO alpha
>> $ cc -O -o test_thread_funcs test_thread_funcs.c
>> test_thread_funcs.c:27: pthread.h: No such file or directory
>> $ cc -O -pthread -o test_thread_funcs test_thread_funcs.c
>> cc: unrecognized option `-pthread'
>> test_thread_funcs.c:27: pthread.h: No such file or directory
>> $ cc -O -pthreads -o test_thread_funcs test_thread_funcs.c
>> cc: unrecognized option `-pthreads'
>> test_thread_funcs.c:27: pthread.h: No such file or directory
>> $ locate pthread.h
>
> Wow, that is strange.  Someone else told me NetBSD supports threads, and
> doesn't need any special compile flags, but of course, it has to have
> pthread.h to support threads.  NetBSD 1.6.1 is very current, so it isn't
> an old OS.
>
> Can you compile if you remove the pthread.h include?  No special compile
> flags should be required.
Nope......


$ vi test*
$ cc -O -o test_thread_funcs test_thread_funcs.c
test_thread_funcs.c: In function `main':
test_thread_funcs.c:50: `pthread_t' undeclared (first use in this function)
test_thread_funcs.c:50: (Each undeclared identifier is reported only once
test_thread_funcs.c:50: for each function it appears in.)
test_thread_funcs.c:50: parse error before `thread1'
test_thread_funcs.c:59: `thread1' undeclared (first use in this function)
test_thread_funcs.c:60: `thread2' undeclared (first use in this function)
$




-- 
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
Fri, 12 Sep 2003 12:09:55 -0500
Larry Rosenman <ler@lerctr.org>
Re: Need NetBSD thread tester
Larry Rosenman wrote:
> > Wow, that is strange.  Someone else told me NetBSD supports threads, and
> > doesn't need any special compile flags, but of course, it has to have
> > pthread.h to support threads.  NetBSD 1.6.1 is very current, so it isn't
> > an old OS.
> >
> > Can you compile if you remove the pthread.h include?  No special compile
> > flags should be required.
> Nope......
> 
> 
> $ vi test*
> $ cc -O -o test_thread_funcs test_thread_funcs.c
> test_thread_funcs.c: In function `main':
> test_thread_funcs.c:50: `pthread_t' undeclared (first use in this function)
> test_thread_funcs.c:50: (Each undeclared identifier is reported only once
> test_thread_funcs.c:50: for each function it appears in.)
> test_thread_funcs.c:50: parse error before `thread1'
> test_thread_funcs.c:59: `thread1' undeclared (first use in this function)
> test_thread_funcs.c:60: `thread2' undeclared (first use in this function)
> $

There a pthrads package you have to install, (pkgsrc/devel/pth):

	http://groups.google.com/groups?q=netbsd+threads+pthread.h&start=30&hl=en&lr=&ie=UTF-8&selm=bhio3i%24cnp%241%40FreeBSD.csie.NCTU.edu.tw&rnum=35

Seems 2.0 will have native threads support.  Now, how does this relate
to libc's thread-safeness?

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

Fri, 12 Sep 2003 13:30:38 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Need NetBSD thread tester
--On Friday, September 12, 2003 13:30:38 -0400 Bruce Momjian 
<pgman@candle.pha.pa.us> wrote:

> Larry Rosenman wrote:
>> > Wow, that is strange.  Someone else told me NetBSD supports threads,
>> > and doesn't need any special compile flags, but of course, it has to
>> > have pthread.h to support threads.  NetBSD 1.6.1 is very current, so
>> > it isn't an old OS.
>> >
>> > Can you compile if you remove the pthread.h include?  No special
>> > compile flags should be required.
>> Nope......
>>
>>
>> $ vi test*
>> $ cc -O -o test_thread_funcs test_thread_funcs.c
>> test_thread_funcs.c: In function `main':
>> test_thread_funcs.c:50: `pthread_t' undeclared (first use in this
>> function) test_thread_funcs.c:50: (Each undeclared identifier is
>> reported only once test_thread_funcs.c:50: for each function it appears
>> in.)
>> test_thread_funcs.c:50: parse error before `thread1'
>> test_thread_funcs.c:59: `thread1' undeclared (first use in this function)
>> test_thread_funcs.c:60: `thread2' undeclared (first use in this function)
>> $
>
> There a pthrads package you have to install, (pkgsrc/devel/pth):
>
> 	http://groups.google.com/groups?q=netbsd+threads+pthread.h&start=30&hl=e
> n&lr=&ie=UTF-8&selm=bhio3i%24cnp%241%40FreeBSD.csie.NCTU.edu.tw&rnum=35
>
> Seems 2.0 will have native threads support.  Now, how does this relate
> to libc's thread-safeness?
Bruce,
    I cc'd you on a note from milo.cirr.com's owner.

That may shed some light.

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
Fri, 12 Sep 2003 12:32:28 -0500
Larry Rosenman <ler@lerctr.org>
Re: Need NetBSD thread tester
<quote who="Bruce Momjian">

> Wow, that is strange.  Someone else told me NetBSD supports threads, and
> doesn't need any special compile flags, but of course, it has to have
> pthread.h to support threads.  NetBSD 1.6.1 is very current, so it isn't
> an old OS.

NetBSD-1.6.1 doesn't have native thread. NetBSD-current has it though.

Thomas T. Thai




Fri, 12 Sep 2003 12:47:54 -0500 (CDT)
"Thomas T. Thai" <tom@minnesota.com>
Re: Need NetBSD thread tester
[ I have retained the original email below so people can remember where
we left this.]

After much agonizing, I have applied a patch to attempt threading in
this order:

      use non-*_r function names if they are all thread-safe
	  (NEED_REENTRANT_FUNCS=no)
      use *_r functions if they exist (configure test)
      do our own locking and copying of non-threadsafe functions

With Solaris, FreeBSD, and OSF failing our existing setup, the last
option of doing our own locking and copying seemed necessary.  The good
news is that this is used only if another method can not be found.  I
used the 'bind' source code as an example of how to do this.

Patch sent to patches list.

---------------------------------------------------------------------------

Bruce Momjian wrote:
> Philip Yarra wrote:
> > On Thu, 4 Sep 2003 05:36 am, Bruce Momjian wrote:
> > > I would like every operating system that supports thread-safety to run
> > > this program and report back the results.
> > 
> > Okay, here's results from the machines I have access to... I think what you're 
> > going to find is that an awful lot of platforms that do support pthreads do 
> > not necessarily provide thread-safe libc functions. 
> 
> I see --- looks bad ---- failures below for OSF, Solaris, and FreeBSD
> below.
> 
> > Is it possible to identify which functions are likely to be called by multiple 
> > threads and create our own mutex-wrapper functions for them? Disabling 
> > thread-safety seems pretty drastic simply because of a lack of getpwuid_r() 
> > or thread-safe getpwuid(). Or do I misunderstand your concerns?
> 
> I am starting to think your approach is the only way to go --- I was
> thinking of it for FreeBSD, but now, with these additional platforms, it
> seems almost a requirement.
> 
> We would have to get some thread mutex, make the function call, copy the
> return values into the passed pointer, and release the mutex?  Do we
> test to see if we are in thread mode before doing the locking?  Is that
> test even possible or desirable?
> 
> Seems we will need to rename the config variable to be
> NON_REENTRANT_FUNC_NAMES_THREADSAFE, and add configure checks for each
> *_r function, and fall back to the mutex if both settings are false.
> 
> This part has me concerned too:
> 
> > Copying the struct hostent does not suffice, since it contains
> > pointers  -  a  deep copy is required.
> 
> Would someone with thread mutex experience assist me?
> 
> 
> ---------------------------------------------------------------------------
> 
> > 
> > Regards, Philip.
> > 
> > $ uname -a
> > OSF1 hostname V4.0 1229 alpha
> > $ ./a.out 
> > Your getpwuid() changes the static memory area between calls
> > Your strerror() is _not_ thread-safe
> > Your functions are _not_ all thread-safe
> > 
> > There are older _r functions, but they're deprecated as the non _r are now 
> > thread-safe.
> > 
> > $ uname -a
> > SunOS hostname 5.6 Generic_105181-05 sun4m sparc SUNW,SPARCstation-4
> > $ gcc -lpthread -lnsl test.c # this works
> > $ ./a.out
> > Your gethostbyname() is _not_ thread-safe
> > Your getpwuid() is _not_ thread-safe
> > Your functions are _not_ all thread-safe
> > 
> > getpwduid_r provided
> > gethostbyname_r not provided
> > 
> > FreeBSD 5.1 (i386)
> > $ cc -pthread test.c
> > $ ./a.out
> > Your gethostbyname() is _not_ thread-safe
> > Your getpwuid() is _not_ thread-safe
> > Your functions are _not_ all thread-safe
> > 
> > manpage notes "BUGS
> >      These functions use static data storage; if the data is needed for future
> >      use, it should be copied before any subsequent calls overwrite it."
> > 
> > FreeBSD 4.8 (i386)
> > $ cc -pthread test.c
> > $ ./a.out
> > Your gethostbyname() is _not_ thread-safe
> > Your getpwuid() is _not_ thread-safe
> > Your functions are _not_ all thread-safe
> > 
> > manpage notes "BUGS
> >      These functions use static data storage; if the data is needed for future
> >      use, it should be copied before any subsequent calls overwrite it."
> > 
> > Linux 2.4.18-3 (i686)
> > $ ./a.out
> > Your gethostbyname() is _not_ thread-safe
> > Your getpwuid() is _not_ thread-safe
> > Your functions are _not_ all thread-safe
> > 
> > manpage notes "The  functions  gethostbyname()  and gethostbyaddr() may return 
> > pointers to static data, which may be over-
> >        written by later calls. Copying the struct hostent does not suffice, 
> > since it contains pointers  -  a  deep
> >        copy is required.
> > 
> > Glibc2 also has reentrant versions gethostbyname_r() and gethostbyname2_r().  
> > These return 0 on success and
> >        nonzero  on  error.  The  result of the call is now stored in the 
> > struct with address ret.  After the call,
> >        *result will be NULL on error or point to the result on success.  
> > Auxiliary data is stored  in  the  buffer
> >        buf  of  length buflen.  (If the buffer is too small, these functions 
> > will return ERANGE.)  No global vari-
> >        able h_errno is modified, but the address of a variable in which  to  
> > store  error  numbers  is  passed  in
> >        h_errnop."
> > 
> 
> -- 
>   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
> 
> ---------------------------(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

Index: configure.in
===================================================================
RCS file: /cvsroot/pgsql-server/configure.in,v
retrieving revision 1.287
diff -c -c -r1.287 configure.in
*** configure.in	12 Sep 2003 16:10:26 -0000	1.287
--- configure.in	13 Sep 2003 14:47:43 -0000
***************
*** 1031,1047 ****
  # One trick here is that if we don't call AC_CHECK_FUNCS, the
  # functions are marked "not found", which is perfect.
  #
! if test "$enable_thread_safety" = yes -a "$NEED_REENTRANT_FUNC_NAMES" = yes ; then
  _CFLAGS="$CFLAGS"
  _LIBS="$LIBS"
  CFLAGS="$CFLAGS $THREAD_CFLAGS"
  LIBS="$LIBS $THREAD_LIBS"
! AC_CHECK_FUNC(strerror_r,
! 	[], [AC_MSG_ERROR([strerror_r not found, required on this platform for --enable-thread-safety])])
! AC_CHECK_FUNC(getpwuid_r,
! 	[], [AC_MSG_ERROR([getpwuid_r not found, required on this platform for --enable-thread-safety])])
! AC_CHECK_FUNC(gethostbyname_r,
! 	[], [AC_MSG_ERROR([gethostbyname_r not found, required on this platform for --enable-thread-safety])])
  CFLAGS="$_CFLAGS"
  LIBS="$_LIBS"
  fi
--- 1031,1042 ----
  # One trick here is that if we don't call AC_CHECK_FUNCS, the
  # functions are marked "not found", which is perfect.
  #
! if test "$enable_thread_safety" = yes -a "$NEED_REENTRANT_FUNCS" = yes ; then
  _CFLAGS="$CFLAGS"
  _LIBS="$LIBS"
  CFLAGS="$CFLAGS $THREAD_CFLAGS"
  LIBS="$LIBS $THREAD_LIBS"
! AC_CHECK_FUNCS([strerror_r getpwuid_r gethostbyname_r])
  CFLAGS="$_CFLAGS"
  LIBS="$_LIBS"
  fi
Index: src/include/port.h
===================================================================
RCS file: /cvsroot/pgsql-server/src/include/port.h,v
retrieving revision 1.13
diff -c -c -r1.13 port.h
*** src/include/port.h	5 Sep 2003 17:43:39 -0000	1.13
--- src/include/port.h	13 Sep 2003 14:47:46 -0000
***************
*** 114,124 ****
  
  #ifndef WIN32
  extern int pqGetpwuid(uid_t uid, struct passwd * resultbuf, char *buffer,
! 		   size_t buflen, struct passwd ** result);
  #endif
  
  extern int pqGethostbyname(const char *name,
! 				struct hostent * resbuf,
! 				char *buf, size_t buflen,
! 				struct hostent ** result,
  				int *herrno);
--- 114,124 ----
  
  #ifndef WIN32
  extern int pqGetpwuid(uid_t uid, struct passwd * resultbuf, char *buffer,
! 		   size_t buflen, struct passwd **result);
  #endif
  
  extern int pqGethostbyname(const char *name,
! 				struct hostent *resultbuf,
! 				char *buffer, size_t buflen,
! 				struct hostent **result,
  				int *herrno);
Index: src/port/thread.c
===================================================================
RCS file: /cvsroot/pgsql-server/src/port/thread.c,v
retrieving revision 1.6
diff -c -c -r1.6 thread.c
*** src/port/thread.c	5 Sep 2003 17:43:40 -0000	1.6
--- src/port/thread.c	13 Sep 2003 14:47:47 -0000
***************
*** 14,25 ****
  
  #include "postgres.h"
  
  /*
   *	Threading sometimes requires specially-named versions of functions
   *	that return data in static buffers, like strerror_r() instead of
   *	strerror().  Other operating systems use pthread_setspecific()
   *	and pthread_getspecific() internally to allow standard library
!  *	functions to return static data to threaded applications.
   *
   *	Additional confusion exists because many operating systems that
   *	use pthread_setspecific/pthread_getspecific() also have *_r versions
--- 14,30 ----
  
  #include "postgres.h"
  
+ #include <pthread.h>
+ #include <sys/types.h>
+ #include <pwd.h>
+ 
  /*
   *	Threading sometimes requires specially-named versions of functions
   *	that return data in static buffers, like strerror_r() instead of
   *	strerror().  Other operating systems use pthread_setspecific()
   *	and pthread_getspecific() internally to allow standard library
!  *	functions to return static data to threaded applications. And some
!  *	operating systems have neither, meaning we have to do our own locking.
   *
   *	Additional confusion exists because many operating systems that
   *	use pthread_setspecific/pthread_getspecific() also have *_r versions
***************
*** 36,46 ****
   *	doesn't have strerror_r(), so we can't fall back to only using *_r
   *	functions for threaded programs.
   *
!  *	The current setup is to assume either all standard functions are
!  *	thread-safe (NEED_REENTRANT_FUNC_NAMES=no), or the operating system
!  *	requires reentrant function names (NEED_REENTRANT_FUNC_NAMES=yes).
   *	Compile and run src/tools/test_thread_funcs.c to see if your operating
!  *	system requires reentrant function names.
   */
   
  
--- 41,55 ----
   *	doesn't have strerror_r(), so we can't fall back to only using *_r
   *	functions for threaded programs.
   *
!  *	The current setup is to try threading in this order:
!  *
!  *		use non-*_r function names if they are all thread-safe
!  *			(NEED_REENTRANT_FUNCS=no)
!  *		use *_r functions if they exist (configure test)
!  *		do our own locking and copying of non-threadsafe functions
!  *
   *	Compile and run src/tools/test_thread_funcs.c to see if your operating
!  *	system has thread-safe non-*_r functions.
   */
   
  
***************
*** 51,64 ****
  char *
  pqStrerror(int errnum, char *strerrbuf, size_t buflen)
  {
! #if defined(USE_THREADS) && defined(NEED_REENTRANT_FUNC_NAMES)
  	/* reentrant strerror_r is available */
  	/* some early standards had strerror_r returning char * */
  	strerror_r(errnum, strerrbuf, buflen);
! 	return (strerrbuf);
  #else
  	/* no strerror_r() available, just use strerror */
! 	return strerror(errnum);
  #endif
  }
  
--- 60,86 ----
  char *
  pqStrerror(int errnum, char *strerrbuf, size_t buflen)
  {
! #if defined(FRONTEND) && defined(USE_THREADS) && defined(NEED_REENTRANT_FUNCS) && defined(HAVE_STRERROR_R)
  	/* reentrant strerror_r is available */
  	/* some early standards had strerror_r returning char * */
  	strerror_r(errnum, strerrbuf, buflen);
! 	return strerrbuf;
! 
  #else
+ 
+ #if defined(FRONTEND) && defined(USE_THREADS) && defined(NEED_REENTRANT_FUNCS) && !defined(HAVE_STRERROR_R)
+ 	static pthread_mutex_t strerror_lock = PTHREAD_MUTEX_INITIALIZER;
+ 	pthread_mutex_lock(&strerror_lock);
+ #endif
+ 
  	/* no strerror_r() available, just use strerror */
! 	StrNCpy(strerrbuf, strerror(errnum), buflen);
! 
! #if defined(FRONTEND) && defined(USE_THREADS) && defined(NEED_REENTRANT_FUNCS) && !defined(HAVE_STRERROR_R)
! 	pthread_mutex_unlock(&strerror_lock);
! #endif
! 
! 	return strerrbuf;
  #endif
  }
  
***************
*** 71,77 ****
  pqGetpwuid(uid_t uid, struct passwd *resultbuf, char *buffer,
  		   size_t buflen, struct passwd **result)
  {
! #if defined(USE_THREADS) && defined(NEED_REENTRANT_FUNC_NAMES)
  	/*
  	 * Early POSIX draft of getpwuid_r() returns 'struct passwd *'.
  	 *    getpwuid_r(uid, resultbuf, buffer, buflen)
--- 93,99 ----
  pqGetpwuid(uid_t uid, struct passwd *resultbuf, char *buffer,
  		   size_t buflen, struct passwd **result)
  {
! #if defined(FRONTEND) && defined(USE_THREADS) && defined(NEED_REENTRANT_FUNCS) && defined(HAVE_GETPWUID_R)
  	/*
  	 * Early POSIX draft of getpwuid_r() returns 'struct passwd *'.
  	 *    getpwuid_r(uid, resultbuf, buffer, buflen)
***************
*** 79,87 ****
--- 101,152 ----
  	 */
  	/* POSIX version */
  	getpwuid_r(uid, resultbuf, buffer, buflen, result);
+ 
  #else
+ 
+ #if defined(FRONTEND) && defined(USE_THREADS) && defined(NEED_REENTRANT_FUNCS) && !defined(HAVE_GETPWUID_R)
+ 	static pthread_mutex_t getpwuid_lock = PTHREAD_MUTEX_INITIALIZER;
+ 	pthread_mutex_lock(&getpwuid_lock);
+ #endif
+ 
  	/* no getpwuid_r() available, just use getpwuid() */
  	*result = getpwuid(uid);
+ 
+ #if defined(FRONTEND) && defined(USE_THREADS) && defined(NEED_REENTRANT_FUNCS) && !defined(HAVE_GETPWUID_R)
+ 
+ 	/* Use 'buffer' memory for storage of strings used by struct passwd */
+ 	if (*result &&
+ 		strlen((*result)->pw_name) + 1 +
+ 		strlen((*result)->pw_passwd) + 1 +
+ 		strlen((*result)->pw_gecos) + 1 +
+ 		/* skip class if it exists */
+ 		strlen((*result)->pw_dir) + 1 +
+ 		strlen((*result)->pw_shell) + 1 <= buflen)
+ 	{
+ 		memcpy(resultbuf, *result, sizeof(struct passwd));
+ 		strcpy(buffer, (*result)->pw_name);
+ 		resultbuf->pw_name = buffer;
+ 		buffer += strlen(resultbuf->pw_name) + 1;
+ 		strcpy(buffer, (*result)->pw_passwd);
+ 		resultbuf->pw_passwd = buffer;
+ 		buffer += strlen(resultbuf->pw_passwd) + 1;
+ 		strcpy(buffer, (*result)->pw_gecos);
+ 		resultbuf->pw_gecos = buffer;
+ 		buffer += strlen(resultbuf->pw_gecos) + 1;
+ 		strcpy(buffer, (*result)->pw_dir);
+ 		resultbuf->pw_dir = buffer;
+ 		buffer += strlen(resultbuf->pw_dir) + 1;
+ 		strcpy(buffer, (*result)->pw_shell);
+ 		resultbuf->pw_shell = buffer;
+ 		buffer += strlen(resultbuf->pw_shell) + 1;
+ 
+ 		*result = resultbuf;
+ 	}
+ 	else
+ 		*result = NULL;
+ 
+ 	pthread_mutex_unlock(&getpwuid_lock);
+ #endif
  #endif
  	return (*result == NULL) ? -1 : 0;
  }
***************
*** 93,119 ****
   */
  int
  pqGethostbyname(const char *name,
! 				struct hostent *resbuf,
! 				char *buf, size_t buflen,
  				struct hostent **result,
  				int *herrno)
  {
! #if defined(USE_THREADS) && defined(NEED_REENTRANT_FUNC_NAMES)
  	/*
  	 * broken (well early POSIX draft) gethostbyname_r() which returns
  	 * 'struct hostent *'
  	 */
! 	*result = gethostbyname_r(name, resbuf, buf, buflen, herrno);
  	return (*result == NULL) ? -1 : 0;
  #else
  	/* no gethostbyname_r(), just use gethostbyname() */
  	*result = gethostbyname(name);
  	if (*result != NULL)
  		return 0;
  	else
- 	{
- 		*herrno = h_errno;
  		return -1;
- 	}
  #endif
  }
--- 158,258 ----
   */
  int
  pqGethostbyname(const char *name,
! 				struct hostent *resultbuf,
! 				char *buffer, size_t buflen,
  				struct hostent **result,
  				int *herrno)
  {
! #if defined(FRONTEND) && defined(USE_THREADS) && defined(NEED_REENTRANT_FUNCS) && defined(HAVE_GETHOSTBYNAME_R)
  	/*
  	 * broken (well early POSIX draft) gethostbyname_r() which returns
  	 * 'struct hostent *'
  	 */
! 	*result = gethostbyname_r(name, resbuf, buffer, buflen, herrno);
  	return (*result == NULL) ? -1 : 0;
+ 
  #else
+ 
+ #if defined(FRONTEND) && defined(USE_THREADS) && defined(NEED_REENTRANT_FUNCS) && !defined(HAVE_GETHOSTBYNAME_R)
+ 	static pthread_mutex_t gethostbyname_lock = PTHREAD_MUTEX_INITIALIZER;
+ 	pthread_mutex_lock(&gethostbyname_lock);
+ #endif
+ 
  	/* no gethostbyname_r(), just use gethostbyname() */
  	*result = gethostbyname(name);
+ 
+ #if defined(FRONTEND) && defined(USE_THREADS) && defined(NEED_REENTRANT_FUNCS) && !defined(HAVE_GETHOSTBYNAME_R)
+ 
+ 	/*
+ 	 *	Use 'buffer' memory for storage of structures used by struct hostent.
+ 	 *	The layout is:
+ 	 *
+ 	 *		addr pointers
+ 	 *		alias pointers
+ 	 *		addr structures
+ 	 *		alias structures
+ 	 *		name
+ 	 */
+ 	if (*result)
+ 	{
+ 		int		i, pointers = 2 /* for nulls */, len = 0;
+ 		char	**pbuffer;
+ 
+ 		for (i = 0; (*result)->h_addr_list[i]; i++, pointers++)
+ 			len += (*result)->h_length;
+ 		for (i = 0; (*result)->h_aliases[i]; i++, pointers++)
+ 			len += (*result)->h_length;
+ 
+ 		if (MAXALIGN(len) + pointers * sizeof(char *) + strlen((*result)->h_name) + 1 <= buflen)
+ 		{
+ 			memcpy(resultbuf, *result, sizeof(struct hostent));
+ 
+     		pbuffer = (char **)buffer;
+     		resultbuf->h_addr_list = pbuffer;
+     		buffer += pointers * sizeof(char *);
+ 
+ 			for (i = 0; (*result)->h_addr_list[i]; i++, pbuffer++)
+ 			{
+ 				memcpy(buffer, (*result)->h_addr_list[i], (*result)->h_length);
+     			resultbuf->h_addr_list[i] = buffer;
+     			buffer += (*result)->h_length;
+     		}
+ 			resultbuf->h_addr_list[i] = NULL;
+ 			pbuffer++;
+ 			    
+     		resultbuf->h_aliases = pbuffer;
+ 
+ 			for (i = 0; (*result)->h_aliases[i]; i++, pbuffer++)
+ 			{
+ 				memcpy(buffer, (*result)->h_aliases[i], (*result)->h_length);
+     			resultbuf->h_aliases[i] = buffer;
+     			buffer += (*result)->h_length;
+     		}
+ 			resultbuf->h_aliases[i] = NULL;
+ 			pbuffer++;
+ 
+ 			/* Place at end for cleaner alignment */			
+ 			strcpy(buffer, (*result)->h_name);
+ 			resultbuf->h_name = buffer;
+ 			buffer += strlen(resultbuf->h_name) + 1;
+ 
+ 			*result = resultbuf;
+ 		}
+ 		else
+ 			*result = NULL;
+ 	}
+ #endif
+ 
+ 	if (*result != NULL)
+ 		*herrno = h_errno;
+ 		
+ #if defined(FRONTEND) && defined(USE_THREADS) && defined(NEED_REENTRANT_FUNCS) && !defined(HAVE_GETHOSTBYNAME_R)
+ 	pthread_mutex_unlock(&gethostbyname_lock);
+ #endif
+ 
  	if (*result != NULL)
  		return 0;
  	else
  		return -1;
  #endif
  }
Index: src/template/bsdi
===================================================================
RCS file: /cvsroot/pgsql-server/src/template/bsdi,v
retrieving revision 1.13
diff -c -c -r1.13 bsdi
*** src/template/bsdi	3 Sep 2003 20:54:20 -0000	1.13
--- src/template/bsdi	13 Sep 2003 14:47:47 -0000
***************
*** 11,14 ****
  esac
  
  SUPPORTS_THREADS=yes
! NEED_REENTRANT_FUNC_NAMES=no	# verified 4.3 2003-09-03
--- 11,14 ----
  esac
  
  SUPPORTS_THREADS=yes
! NEED_REENTRANT_FUNCS=no	# verified 4.3 2003-09-03
Index: src/template/freebsd
===================================================================
RCS file: /cvsroot/pgsql-server/src/template/freebsd,v
retrieving revision 1.20
diff -c -c -r1.20 freebsd
*** src/template/freebsd	12 Sep 2003 16:49:34 -0000	1.20
--- src/template/freebsd	13 Sep 2003 14:47:47 -0000
***************
*** 4,11 ****
    alpha*)   CFLAGS="$CFLAGS -O" ;;
  esac
  
! SUPPORTS_THREADS=no 	# 4.8, 5.1  2003-09-12
! NEED_REENTRANT_FUNC_NAMES=no
  
  case $host_os in
  		freebsd2*|freebsd3*|freebsd4*)
--- 4,11 ----
    alpha*)   CFLAGS="$CFLAGS -O" ;;
  esac
  
! SUPPORTS_THREADS=yes
! NEED_REENTRANT_FUNCS=yes 	# 4.8, 5.1  2003-09-12
  
  case $host_os in
  		freebsd2*|freebsd3*|freebsd4*)
Index: src/template/linux
===================================================================
RCS file: /cvsroot/pgsql-server/src/template/linux,v
retrieving revision 1.13
diff -c -c -r1.13 linux
*** src/template/linux	3 Sep 2003 22:34:08 -0000	1.13
--- src/template/linux	13 Sep 2003 14:47:47 -0000
***************
*** 1,7 ****
  CFLAGS=-O2
  
  SUPPORTS_THREADS=yes
! NEED_REENTRANT_FUNC_NAMES=yes	# verified glibc 2.1 2003-09-03
  THREAD_CFLAGS="-D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS"
  THREAD_LIBS="-lpthread"
  
--- 1,7 ----
  CFLAGS=-O2
  
  SUPPORTS_THREADS=yes
! NEED_REENTRANT_FUNCS=yes	# verified glibc 2.1 2003-09-03
  THREAD_CFLAGS="-D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS"
  THREAD_LIBS="-lpthread"
  
Index: src/template/netbsd
===================================================================
RCS file: /cvsroot/pgsql-server/src/template/netbsd,v
retrieving revision 1.10
diff -c -c -r1.10 netbsd
*** src/template/netbsd	16 Aug 2003 15:35:51 -0000	1.10
--- src/template/netbsd	13 Sep 2003 14:47:47 -0000
***************
*** 1,4 ****
  CFLAGS='-O2 -pipe'
  
  SUPPORTS_THREADS=yes
! NEED_REENTRANT_FUNC_NAMES=no
--- 1,4 ----
  CFLAGS='-O2 -pipe'
  
  SUPPORTS_THREADS=yes
! NEED_REENTRANT_FUNCS=no
Index: src/template/osf
===================================================================
RCS file: /cvsroot/pgsql-server/src/template/osf,v
retrieving revision 1.7
diff -c -c -r1.7 osf
*** src/template/osf	16 Aug 2003 15:35:51 -0000	1.7
--- src/template/osf	13 Sep 2003 14:47:47 -0000
***************
*** 6,10 ****
  fi
  
  SUPPORTS_THREADS=yes
! NEED_REENTRANT_FUNC_NAMES=no
  THREAD_CFLAGS="-pthread"
--- 6,10 ----
  fi
  
  SUPPORTS_THREADS=yes
! NEED_REENTRANT_FUNCS=no		# 4.0 2003-09-13
  THREAD_CFLAGS="-pthread"
Index: src/template/solaris
===================================================================
RCS file: /cvsroot/pgsql-server/src/template/solaris,v
retrieving revision 1.2
diff -c -c -r1.2 solaris
*** src/template/solaris	21 Oct 2000 22:36:14 -0000	1.2
--- src/template/solaris	13 Sep 2003 14:47:47 -0000
***************
*** 4,6 ****
--- 4,11 ----
    CC="$CC -Xa"			# relaxed ISO C mode
    CFLAGS=-v			# -v is like gcc -Wall
  fi
+ 
+ SUPPORTS_THREADS=yes
+ NEED_REENTRANT_FUNCS=yes	# 5.6 2003-09-13
+ THREAD_CFLAGS="-pthread"
+ 
Index: src/template/unixware
===================================================================
RCS file: /cvsroot/pgsql-server/src/template/unixware,v
retrieving revision 1.21
diff -c -c -r1.21 unixware
*** src/template/unixware	3 Sep 2003 20:54:21 -0000	1.21
--- src/template/unixware	13 Sep 2003 14:47:47 -0000
***************
*** 10,14 ****
  fi
  
  SUPPORTS_THREADS=yes
! NEED_REENTRANT_FUNC_NAMES=no	# verified 7.1.3 2003-09-03
  THREAD_CFLAGS="$THREAD_CFLAGS -D_REENTRANT"
--- 10,14 ----
  fi
  
  SUPPORTS_THREADS=yes
! NEED_REENTRANT_FUNCS=no		# verified 7.1.3 2003-09-03
  THREAD_CFLAGS="$THREAD_CFLAGS -D_REENTRANT"
Sat, 13 Sep 2003 10:48:36 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)