--On Thursday, May 13, 2004 10:05:22 -0400 Bruce Momjian 
<pgman@candle.pha.pa.us> wrote:


> Basically, as things set right now in CVS, Unixware is ready to go
> because it thread for everything.  We don't have per-template thread
> settings anymore because we test all of it in configure.

Was a change made to link initdb et al with -Kpthread?  It doesn't seem to
be in AnonCVS yet.



-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 972-414-9812                 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Thu, 13 May 2004 10:36:37 -0500
Larry Rosenman <ler@lerctr.org>
Re: threads stuff/UnixWare
Larry Rosenman wrote:
-- Start of PGP signed section.
> 
> 
> --On Thursday, May 13, 2004 10:05:22 -0400 Bruce Momjian 
> <pgman@candle.pha.pa.us> wrote:
> 
> 
> > Basically, as things set right now in CVS, Unixware is ready to go
> > because it thread for everything.  We don't have per-template thread
> > settings anymore because we test all of it in configure.
> 
> Was a change made to link initdb et al with -Kpthread?  It doesn't seem to
> be in AnonCVS yet.

Really?  You are configuring with --enable-thread-safety?  I just
updated your template in CVS, and it is attached.  However, any old CVS
should work fine.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

if test "$GCC" != yes; then
then
  # The -Kno_host is for a bug in the compiler.  See -hackers
  # discussion on 7-8/Aug/2003.
  cat >conftest.c <<__EOF__
extern char *strcpy(char *, const char *);

static void f(char *p, int n){
        strcpy(p+n,"");
}
void g(void){
        f(0, 0);
}
__EOF__

  if $CC -c -O -Kinline conftest.c >conftest.err 2>&1; then
    CFLAGS="-O -Kinline"
  else
    CFLAGS="-O -Kinline,no_host"
  fi
  rm -f conftest.*

  PTHREAD_CFLAGS="-Kpthread"
fi
Thu, 13 May 2004 11:44:59 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: threads stuff/UnixWare
--On Thursday, May 13, 2004 11:44:59 -0400 Bruce Momjian 
<pgman@candle.pha.pa.us> wrote:

> Larry Rosenman wrote:
> -- Start of PGP signed section.
>>
>>
>> --On Thursday, May 13, 2004 10:05:22 -0400 Bruce Momjian
>> <pgman@candle.pha.pa.us> wrote:
>>
>>
>> > Basically, as things set right now in CVS, Unixware is ready to go
>> > because it thread for everything.  We don't have per-template thread
>> > settings anymore because we test all of it in configure.
>>
>> Was a change made to link initdb et al with -Kpthread?  It doesn't seem
>> to be in AnonCVS yet.
>
> Really?  You are configuring with --enable-thread-safety?  I just
> updated your template in CVS, and it is attached.  However, any old CVS
> should work fine.
Nope, initdb is where we still die:

cc -O -Kinline initdb.o exec.o -L../../../src/interfaces/libpq -lpq 
-L../../../src/port -L/usr/local/lib -Wl,-R/usr/local/pgsql/lib -lz 
-lreadline -ltermcap -lresolv -lgen -lld -lsocket -lnsl -ldl -lm  -lpgport 
-o initdb
Undefined                       first referenced
symbol                              in file
pthread_mutex_unlock                libpq.so
pthread_getspecific                 libpq.so
pthread_mutex_lock                  libpq.so
pthread_key_create                  libpq.so
pthread_once                        libpq.so
pthread_setspecific                 libpq.so
UX:ld: ERROR: Symbol referencing errors. No output written to initdb
gmake[3]: *** [initdb] Error 1
gmake[3]: Leaving directory `/home/ler/pg-dev/pgsql-server/src/bin/initdb'
gmake[2]: *** [all] Error 2
gmake[2]: Leaving directory `/home/ler/pg-dev/pgsql-server/src/bin'
gmake[1]: *** [all] Error 2
gmake[1]: Leaving directory `/home/ler/pg-dev/pgsql-server/src'
gmake: *** [all] Error 2
$


-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 972-414-9812                 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Thu, 13 May 2004 10:47:46 -0500
Larry Rosenman <ler@lerctr.org>
Re: threads stuff/UnixWare
Larry Rosenman wrote:
> > Really?  You are configuring with --enable-thread-safety?  I just
> > updated your template in CVS, and it is attached.  However, any old CVS
> > should work fine.
> Nope, initdb is where we still die:
> 

OH!  I remember now.  What we have to do for this platform only is to
pass the thread flags into all compile/links.  I forgot that step.

Let me work on that and send you a patch.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Thu, 13 May 2004 11:50:56 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: threads stuff/UnixWare
Larry Rosenman wrote:
> > Really?  You are configuring with --enable-thread-safety?  I just
> > updated your template in CVS, and it is attached.  However, any old CVS
> > should work fine.
> Nope, initdb is where we still die:

Patch applied:

Force thread flags for all Unixware builds if threading is requested.

This is required because once you link with a library that uses threads,
all references to that library have to use thread flags.

-- 
  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: src/Makefile.global.in
===================================================================
RCS file: /cvsroot/pgsql-server/src/Makefile.global.in,v
retrieving revision 1.182
diff -c -c -r1.182 Makefile.global.in
*** src/Makefile.global.in	11 May 2004 21:57:14 -0000	1.182
--- src/Makefile.global.in	13 May 2004 23:03:12 -0000
***************
*** 177,182 ****
--- 177,188 ----
    CFLAGS += -Wall -Wmissing-prototypes -Wmissing-declarations
  endif
  
+ # Unixware needs threads for everything that uses libpq
+ ifeq ($(PORTNAME),unixware)
+   CFLAGS += "$PTHREAD_CFLAGS"
+ endif
+ 
+ 
  # Kind-of compilers
  
  YACC = @YACC@
Thu, 13 May 2004 19:06:15 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] threads stuff/UnixWare
--On Thursday, May 13, 2004 19:06:15 -0400 Bruce Momjian 
<pgman@candle.pha.pa.us> wrote:

> Larry Rosenman wrote:
>> > Really?  You are configuring with --enable-thread-safety?  I just
>> > updated your template in CVS, and it is attached.  However, any old CVS
>> > should work fine.
>> Nope, initdb is where we still die:
>
> Patch applied:
>
> Force thread flags for all Unixware builds if threading is requested.
>
> This is required because once you link with a library that uses threads,
> all references to that library have to use thread flags.


I manually added that patch, and re-did configure, et al from a gmake 
maintainer-clean, and we still die at initdb:

cc -O -Kinline initdb.o exec.o -L../../../src/interfaces/libpq -lpq 
-L../../../src/port -L/usr/local/lib -Wl,-R/usr/local/pgsql/lib -lz 
-lreadline -ltermcap -lresolv -lgen -lld -lsocket -lnsl -ldl -lm  -lpgport 
-o initdb
Undefined                       first referenced
symbol                              in file
pthread_mutex_unlock                libpq.so
pthread_getspecific                 libpq.so
pthread_mutex_lock                  libpq.so
pthread_key_create                  libpq.so
pthread_once                        libpq.so
pthread_setspecific                 libpq.so
UX:ld: ERROR: Symbol referencing errors. No output written to initdb
gmake[3]: *** [initdb] Error 1
gmake[3]: Leaving directory `/home/ler/pg-dev/pgsql-server/src/bin/initdb'
gmake[2]: *** [all] Error 2
gmake[2]: Leaving directory `/home/ler/pg-dev/pgsql-server/src/bin'
gmake[1]: *** [all] Error 2
gmake[1]: Leaving directory `/home/ler/pg-dev/pgsql-server/src'
gmake: *** [all] Error 2
[1] +  Done(2)                 gmake >gmake.out 2>&1 &
$

-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 972-414-9812                 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Thu, 13 May 2004 18:28:14 -0500
Larry Rosenman <ler@lerctr.org>
Re: [HACKERS] threads stuff/UnixWare
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> *** src/Makefile.global.in	11 May 2004 21:57:14 -0000	1.182
> --- src/Makefile.global.in	13 May 2004 23:03:12 -0000
> ***************
> *** 177,182 ****
> --- 177,188 ----
>     CFLAGS += -Wall -Wmissing-prototypes -Wmissing-declarations
>   endif
  
> + # Unixware needs threads for everything that uses libpq
> + ifeq ($(PORTNAME),unixware)
> +   CFLAGS += "$PTHREAD_CFLAGS"
> + endif
> + 
> + 
>   # Kind-of compilers
  
>   YACC = @YACC@


Yech.  Isn't this what the Makefile.port files are for?  Makefile.global
should never contain any "#ifdef port" junk.


			regards, tom lane

Thu, 13 May 2004 19:46:00 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] threads stuff/UnixWare 
\Larry Rosenman wrote:
> > This is required because once you link with a library that uses threads,
> > all references to that library have to use thread flags.
> 
> 
> I manually added that patch, and re-did configure, et al from a gmake 
> maintainer-clean, and we still die at initdb:
> 
> cc -O -Kinline initdb.o exec.o -L../../../src/interfaces/libpq -lpq 
> -L../../../src/port -L/usr/local/lib -Wl,-R/usr/local/pgsql/lib -lz 
> -lreadline -ltermcap -lresolv -lgen -lld -lsocket -lnsl -ldl -lm  -lpgport 
> -o initdb

OK, we need to see -Kpthread in that compile line.  Would you look at
Makefile.global at where I add the thread flags to see why isn't
working.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Thu, 13 May 2004 19:52:56 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] threads stuff/UnixWare
--On Thursday, May 13, 2004 19:46:00 -0400 Tom Lane <tgl@sss.pgh.pa.us> 
wrote:

> Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> *** src/Makefile.global.in	11 May 2004 21:57:14 -0000	1.182
>> --- src/Makefile.global.in	13 May 2004 23:03:12 -0000
>> ***************
>> *** 177,182 ****
>> --- 177,188 ----
>>     CFLAGS += -Wall -Wmissing-prototypes -Wmissing-declarations
>>   endif
>
>> + # Unixware needs threads for everything that uses libpq
>> + ifeq ($(PORTNAME),unixware)
>> +   CFLAGS += "$PTHREAD_CFLAGS"
>> + endif
>> +
>> +
>>   # Kind-of compilers
>
>>   YACC = @YACC@
>
>
> Yech.  Isn't this what the Makefile.port files are for?  Makefile.global
> should never contain any "#ifdef port" junk.
>
>
> 			regards, tom lane

It also appears from testing, that this does NOT fix the initdb issue.

LER


-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 972-414-9812                 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Thu, 13 May 2004 18:53:08 -0500
Larry Rosenman <ler@lerctr.org>
Re: [HACKERS] threads stuff/UnixWare 
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > *** src/Makefile.global.in	11 May 2004 21:57:14 -0000	1.182
> > --- src/Makefile.global.in	13 May 2004 23:03:12 -0000
> > ***************
> > *** 177,182 ****
> > --- 177,188 ----
> >     CFLAGS += -Wall -Wmissing-prototypes -Wmissing-declarations
> >   endif
>   
> > + # Unixware needs threads for everything that uses libpq
> > + ifeq ($(PORTNAME),unixware)
> > +   CFLAGS += "$PTHREAD_CFLAGS"
> > + endif
> > + 
> > + 
> >   # Kind-of compilers
>   
> >   YACC = @YACC@
> 
> 
> Yech.  Isn't this what the Makefile.port files are for?  Makefile.global
> should never contain any "#ifdef port" junk.

So we just add the thing in the template file?  Yea, I can do that.  I
did it there because Win32 already had something for libs.  Does the
template file get included in Makefile.global?  I didn't think so.

Part of the problem is we don't know if they have asked for threads at
the time we load the template file from configure, no?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Thu, 13 May 2004 19:57:09 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] threads stuff/UnixWare
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> So we just add the thing in the template file?  Yea, I can do that.  I
> did it there because Win32 already had something for libs.  Does the
> template file get included in Makefile.global?  I didn't think so.

Not the template, the port-specific makefile.

			regards, tom lane

Thu, 13 May 2004 19:58:55 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] threads stuff/UnixWare 
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > So we just add the thing in the template file?  Yea, I can do that.  I
> > did it there because Win32 already had something for libs.  Does the
> > template file get included in Makefile.global?  I didn't think so.
> 
> Not the template, the port-specific makefile.

Oh, I forgot about those.  Done.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Thu, 13 May 2004 20:03:24 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] threads stuff/UnixWare
--On Thursday, May 13, 2004 20:03:24 -0400 Bruce Momjian 
<pgman@candle.pha.pa.us> wrote:

> Tom Lane wrote:
>> Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> > So we just add the thing in the template file?  Yea, I can do that.  I
>> > did it there because Win32 already had something for libs.  Does the
>> > template file get included in Makefile.global?  I didn't think so.
>>
>> Not the template, the port-specific makefile.
>
> Oh, I forgot about those.  Done.

I did this patch, and it works:


$ cvs diff -u Makefile.unixware
Index: Makefile.unixware
===================================================================
RCS file: /projects/cvsroot/pgsql-server/src/makefiles/Makefile.unixware,v
retrieving revision 1.17
diff -u -r1.17 Makefile.unixware
--- Makefile.unixware   5 Jan 2003 13:45:47 -0000       1.17
+++ Makefile.unixware   14 May 2004 00:06:07 -0000
@@ -25,6 +25,7 @@
 else
 SO_FLAGS = -G
 endif
+CFLAGS += $(PTHREAD_CFLAGS)

 %.so: %.o
        $(CC) $(SO_FLAGS) -o $@ $<
$

-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 972-414-9812                 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Thu, 13 May 2004 19:06:32 -0500
Larry Rosenman <ler@lerctr.org>
Re: [HACKERS] threads stuff/UnixWare

Good. I changed my commit to use your version.

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

Larry Rosenman wrote:
-- Start of PGP signed section.
> 
> 
> --On Thursday, May 13, 2004 20:03:24 -0400 Bruce Momjian 
> <pgman@candle.pha.pa.us> wrote:
> 
> > Tom Lane wrote:
> >> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> >> > So we just add the thing in the template file?  Yea, I can do that.  I
> >> > did it there because Win32 already had something for libs.  Does the
> >> > template file get included in Makefile.global?  I didn't think so.
> >>
> >> Not the template, the port-specific makefile.
> >
> > Oh, I forgot about those.  Done.
> 
> I did this patch, and it works:
> 
> 
> $ cvs diff -u Makefile.unixware
> Index: Makefile.unixware
> ===================================================================
> RCS file: /projects/cvsroot/pgsql-server/src/makefiles/Makefile.unixware,v
> retrieving revision 1.17
> diff -u -r1.17 Makefile.unixware
> --- Makefile.unixware   5 Jan 2003 13:45:47 -0000       1.17
> +++ Makefile.unixware   14 May 2004 00:06:07 -0000
> @@ -25,6 +25,7 @@
>  else
>  SO_FLAGS = -G
>  endif
> +CFLAGS += $(PTHREAD_CFLAGS)
> 
>  %.so: %.o
>         $(CC) $(SO_FLAGS) -o $@ $<
> $
> 
> -- 
> Larry Rosenman                     http://www.lerctr.org/~ler
> Phone: +1 972-414-9812                 E-Mail: ler@lerctr.org
> US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
-- End of PGP section, PGP failed!

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Thu, 13 May 2004 20:11:45 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] threads stuff/UnixWare
--On Thursday, May 13, 2004 20:11:45 -0400 Bruce Momjian 
<pgman@candle.pha.pa.us> wrote:

>
> Good. I changed my commit to use your version.
>


Thanks!

Do we care about regression failures at this stage?

I have int4/int8/join failures (join is not new, and is
an order issue).

the int4/int8 have to do with NaN and Infinity i/o.


-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 972-414-9812                 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Thu, 13 May 2004 19:13:26 -0500
Larry Rosenman <ler@lerctr.org>
Re: [HACKERS] threads stuff/UnixWare
Larry Rosenman <ler@lerctr.org> writes:
> the int4/int8 have to do with NaN and Infinity i/o.

Those we care about.  I was hoping CVS tip would Just Work Everywhere
on that point, but evidently not :-(.  What do you get?  Did it work
better in 7.4?  Does Unixware support NaN/Infinity at all?

			regards, tom lane

Thu, 13 May 2004 20:49:28 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] threads stuff/UnixWare 
--On Thursday, May 13, 2004 20:49:28 -0400 Tom Lane <tgl@sss.pgh.pa.us> 
wrote:

> Larry Rosenman <ler@lerctr.org> writes:
>> the int4/int8 have to do with NaN and Infinity i/o.
>
> Those we care about.  I was hoping CVS tip would Just Work Everywhere
> on that point, but evidently not :-(.  What do you get?  Did it work
> better in 7.4?  Does Unixware support NaN/Infinity at all?
>
> 			regards, tom lane

Yes, we support NaN's and Inf.  From the fscanf manpage:
When matching floating numbers, the locale's decimal point character
   is taken to introduce a fractional portion, the sequences inf and
   infinity (case ignored) are taken to represent infinities, and the
   sequence nan[(m)] (case ignored), where the optional parenthesized m
   consists of zero or more alphanumeric or underscore (_) characters,
   are taken to represent NaNs (not-a-numbers). Note, however, that the
   locale's thousands' separator character will not be recognized as
   such.


I got:

*** ./expected/float4.out	Thu Mar 11 18:25:40 2004
--- ./results/float4.out	Thu May 13 19:08:18 2004
***************
*** 33,67 ****
  ERROR:  invalid input syntax for type real: "123            5"
  -- special inputs
  SELECT 'NaN'::float4;
!  float4
! --------
!     NaN
! (1 row)
!
  SELECT 'nan'::float4;
!  float4
! --------
!     NaN
! (1 row)
!
  SELECT '   NAN  '::float4;
!  float4
! --------
!     NaN
! (1 row)
!
  SELECT 'infinity'::float4;
!   float4
! ----------
!  Infinity
! (1 row)
!
  SELECT '          -INFINiTY   '::float4;
!   float4
! -----------
!  -Infinity
! (1 row)
!
  -- bad special inputs
  SELECT 'N A N'::float4;
  ERROR:  invalid input syntax for type real: "N A N"
--- 33,47 ----
  ERROR:  invalid input syntax for type real: "123            5"
  -- special inputs
  SELECT 'NaN'::float4;
! ERROR:  invalid input syntax for type real: "NaN"
  SELECT 'nan'::float4;
! ERROR:  invalid input syntax for type real: "nan"
  SELECT '   NAN  '::float4;
! ERROR:  invalid input syntax for type real: "   NAN  "
  SELECT 'infinity'::float4;
! ERROR:  invalid input syntax for type real: "infinity"
  SELECT '          -INFINiTY   '::float4;
! ERROR:  invalid input syntax for type real: "          -INFINiTY   "
  -- bad special inputs
  SELECT 'N A N'::float4;
  ERROR:  invalid input syntax for type real: "N A N"
***************
*** 70,88 ****
  SELECT ' INFINITY    x'::float4;
  ERROR:  invalid input syntax for type real: " INFINITY    x"
  SELECT 'Infinity'::float4 + 100.0;
! ERROR:  type "double precision" value out of range: overflow
  SELECT 'Infinity'::float4 / 'Infinity'::float4;
!  ?column?
! ----------
!       NaN
! (1 row)
!
  SELECT 'nan'::float4 / 'nan'::float4;
!  ?column?
! ----------
!       NaN
! (1 row)
!
  SELECT '' AS five, FLOAT4_TBL.*;
   five |     f1
  ------+-------------
--- 50,60 ----
  SELECT ' INFINITY    x'::float4;
  ERROR:  invalid input syntax for type real: " INFINITY    x"
  SELECT 'Infinity'::float4 + 100.0;
! ERROR:  invalid input syntax for type real: "Infinity"
  SELECT 'Infinity'::float4 / 'Infinity'::float4;
! ERROR:  invalid input syntax for type real: "Infinity"
  SELECT 'nan'::float4 / 'nan'::float4;
! ERROR:  invalid input syntax for type real: "nan"
  SELECT '' AS five, FLOAT4_TBL.*;
   five |     f1
  ------+-------------

======================================================================

*** ./expected/float8.out	Fri Apr 23 15:32:20 2004
--- ./results/float8.out	Thu May 13 19:08:18 2004
***************
*** 33,67 ****
  ERROR:  invalid input syntax for type double precision: "123           5"
  -- special inputs
  SELECT 'NaN'::float8;
!  float8
! --------
!     NaN
! (1 row)
!
  SELECT 'nan'::float8;
!  float8
! --------
!     NaN
! (1 row)
!
  SELECT '   NAN  '::float8;
!  float8
! --------
!     NaN
! (1 row)
!
  SELECT 'infinity'::float8;
!   float8
! ----------
!  Infinity
! (1 row)
!
  SELECT '          -INFINiTY   '::float8;
!   float8
! -----------
!  -Infinity
! (1 row)
!
  -- bad special inputs
  SELECT 'N A N'::float8;
  ERROR:  invalid input syntax for type double precision: "N A N"
--- 33,47 ----
  ERROR:  invalid input syntax for type double precision: "123           5"
  -- special inputs
  SELECT 'NaN'::float8;
! ERROR:  invalid input syntax for type double precision: "NaN"
  SELECT 'nan'::float8;
! ERROR:  invalid input syntax for type double precision: "nan"
  SELECT '   NAN  '::float8;
! ERROR:  invalid input syntax for type double precision: "   NAN  "
  SELECT 'infinity'::float8;
! ERROR:  invalid input syntax for type double precision: "infinity"
  SELECT '          -INFINiTY   '::float8;
! ERROR:  invalid input syntax for type double precision: " 
-INFINiTY   "
  -- bad special inputs
  SELECT 'N A N'::float8;
  ERROR:  invalid input syntax for type double precision: "N A N"
***************
*** 70,88 ****
  SELECT ' INFINITY    x'::float8;
  ERROR:  invalid input syntax for type double precision: " INFINITY    x"
  SELECT 'Infinity'::float8 + 100.0;
! ERROR:  type "double precision" value out of range: overflow
  SELECT 'Infinity'::float8 / 'Infinity'::float8;
!  ?column?
! ----------
!       NaN
! (1 row)
!
  SELECT 'nan'::float8 / 'nan'::float8;
!  ?column?
! ----------
!       NaN
! (1 row)
!
  SELECT '' AS five, FLOAT8_TBL.*;
   five |          f1
  ------+----------------------
--- 50,60 ----
  SELECT ' INFINITY    x'::float8;
  ERROR:  invalid input syntax for type double precision: " INFINITY    x"
  SELECT 'Infinity'::float8 + 100.0;
! ERROR:  invalid input syntax for type double precision: "Infinity"
  SELECT 'Infinity'::float8 / 'Infinity'::float8;
! ERROR:  invalid input syntax for type double precision: "Infinity"
  SELECT 'nan'::float8 / 'nan'::float8;
! ERROR:  invalid input syntax for type double precision: "nan"
  SELECT '' AS five, FLOAT8_TBL.*;
   five |          f1
  ------+----------------------

======================================================================

*** ./expected/join.out	Thu Sep 25 01:58:06 2003
--- ./results/join.out	Thu May 13 19:08:49 2004
***************
*** 1732,1739 ****
       | 6 | 6 | six   |
       | 7 | 7 | seven |
       | 8 | 8 | eight |
-      |   |   | null  |
       |   | 0 | zero  |
  (13 rows)

  SELECT '' AS "xxx", *
--- 1732,1739 ----
       | 6 | 6 | six   |
       | 7 | 7 | seven |
       | 8 | 8 | eight |
       |   | 0 | zero  |
+      |   |   | null  |
  (13 rows)

  SELECT '' AS "xxx", *
***************
*** 1752,1759 ****
       | 6 | 6 | six   |
       | 7 | 7 | seven |
       | 8 | 8 | eight |
-      |   |   | null  |
       |   | 0 | zero  |
  (13 rows)

  SELECT '' AS "xxx", *
--- 1752,1759 ----
       | 6 | 6 | six   |
       | 7 | 7 | seven |
       | 8 | 8 | eight |
       |   | 0 | zero  |
+      |   |   | null  |
  (13 rows)

  SELECT '' AS "xxx", *
***************
*** 1793,1800 ****
  -----+---+---+-------+----
       | 0 |   | zero  |
       | 1 | 4 | one   | -1
-      | 2 | 3 | two   |  2
       | 2 | 3 | two   |  4
       | 3 | 2 | three | -3
       | 4 | 1 | four  |
       | 5 | 0 | five  | -5
--- 1793,1800 ----
  -----+---+---+-------+----
       | 0 |   | zero  |
       | 1 | 4 | one   | -1
       | 2 | 3 | two   |  4
+      | 2 | 3 | two   |  2
       | 3 | 2 | three | -3
       | 4 | 1 | four  |
       | 5 | 0 | five  | -5
***************
*** 1815,1822 ****
  -----+---+---+-------+----
       | 0 |   | zero  |
       | 1 | 4 | one   | -1
-      | 2 | 3 | two   |  2
       | 2 | 3 | two   |  4
       | 3 | 2 | three | -3
       | 4 | 1 | four  |
       | 5 | 0 | five  | -5
--- 1815,1822 ----
  -----+---+---+-------+----
       | 0 |   | zero  |
       | 1 | 4 | one   | -1
       | 2 | 3 | two   |  4
+      | 2 | 3 | two   |  2
       | 3 | 2 | three | -3
       | 4 | 1 | four  |
       | 5 | 0 | five  | -5

======================================================================


7.4.* passed all but join.

LER


-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 972-414-9812                 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Thu, 13 May 2004 20:03:53 -0500
Larry Rosenman <ler@lerctr.org>
Re: [HACKERS] threads stuff/UnixWare 
Larry Rosenman <ler@lerctr.org> writes:
>> Does Unixware support NaN/Infinity at all?

> Yes, we support NaN's and Inf.

Hmph.  Apparently their strtod() has thought of some original new way to
misbehave on those inputs.  Would you mind tracing through float4in() or
float8in() to see exactly how it manages to fail?

			regards, tom lane

Thu, 13 May 2004 21:14:40 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] threads stuff/UnixWare 
--On Thursday, May 13, 2004 21:14:40 -0400 Tom Lane <tgl@sss.pgh.pa.us> 
wrote:

> Larry Rosenman <ler@lerctr.org> writes:
>>> Does Unixware support NaN/Infinity at all?
>
>> Yes, we support NaN's and Inf.
>
> Hmph.  Apparently their strtod() has thought of some original new way to
> misbehave on those inputs.  Would you mind tracing through float4in() or
> float8in() to see exactly how it manages to fail?
>
> 			regards, tom lane


I ran a quick C test:

cc -O -o test3 test3.c
$ ./test3
num=nan
errno=0
$ cat test3.c
#include <stdlib.h>
#include <stdio.h>
#include <errno.h>
int main(int argc,char **argv)
{
  double num;
  char *input="NaN";
  char **ptr;

  num=strtod(input,ptr);
  printf("num=%g\n",num);
  printf("errno=%ld\n",errno);
  exit(0);
}


So, how's the easiest way to trace PG's float4in stuff?



-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 972-414-9812                 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Thu, 13 May 2004 20:20:38 -0500
Larry Rosenman <ler@lerctr.org>
Re: [HACKERS] threads stuff/UnixWare 
Larry Rosenman <ler@lerctr.org> writes:
> I ran a quick C test:

Where does it leave the "ptr" pointing to?

> So, how's the easiest way to trace PG's float4in stuff?

gdb is my favorite ...

			regards, tom lane

Thu, 13 May 2004 21:26:50 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] threads stuff/UnixWare 
--On Thursday, May 13, 2004 21:26:50 -0400 Tom Lane <tgl@sss.pgh.pa.us> 
wrote:

> Larry Rosenman <ler@lerctr.org> writes:
>> I ran a quick C test:
>
> Where does it leave the "ptr" pointing to?

$ cc -O -o test3 test3.c
$ ./test3
num=nan
errno=0
ptr=8049682, points to N
num=inf
errno=0
ptr=8049686, points to f
$ cat test3.c
#include <stdlib.h>
#include <stdio.h>
#include <errno.h>
int main(int argc,char **argv)
{
  double num;
  char *input="NaN";
  char *border1="/////////////////////////////";
  char *input2="inf";
  char *border2="/////////////////////////////";
  char **ptr;

  num=strtod(input,ptr);
  printf("num=%g\n",num);
  printf("errno=%ld\n",errno);
  printf("ptr=%p, points to %s\n",*ptr,*ptr);
  num=strtod(input2,ptr);
  printf("num=%g\n",num);
  printf("errno=%ld\n",errno);
  printf("ptr=%p, points to %s\n",*ptr,*ptr);
  exit(0);
}
$


>
>> So, how's the easiest way to trace PG's float4in stuff?
>
> gdb is my favorite ...

and (without installing it), how can I grab gdb on the gmake test 
backend(s)?



-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 972-414-9812                 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Thu, 13 May 2004 20:31:29 -0500
Larry Rosenman <ler@lerctr.org>
Re: [HACKERS] threads stuff/UnixWare 
Larry Rosenman <ler@lerctr.org> writes:
>> Where does it leave the "ptr" pointing to?

> $ ./test3
> ptr=8049682, points to N
> ptr=8049686, points to f

Indeed, they found an original new way to get it wrong.  Please point
out to them that the ptr is supposed to be advanced *past* the input.
Not to the last character of the input.

			regards, tom lane

Thu, 13 May 2004 21:35:43 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] threads stuff/UnixWare 
--On Thursday, May 13, 2004 21:35:43 -0400 Tom Lane <tgl@sss.pgh.pa.us> 
wrote:

> Larry Rosenman <ler@lerctr.org> writes:
>>> Where does it leave the "ptr" pointing to?
>
>> $ ./test3
>> ptr=8049682, points to N
>> ptr=8049686, points to f
>
> Indeed, they found an original new way to get it wrong.  Please point
> out to them that the ptr is supposed to be advanced *past* the input.
> Not to the last character of the input.

Reported to my SCO contacts.  However, I guarantee this won't be fixed in
7.1.4 (the next release), as it just went Gold.

Also, I suspect 7.1.3 and below have the bug, and are prevalent.

And, I just proved it on my 7.1.2 (AKA OpenUNIX 8.0.0) system:

$ cc -O -o test3 test3.c
$ ./test3
num=nan
errno=0
ptr=8049682, points to N
num=inf
errno=0
ptr=8049686, points to f
$ uname -a
OpenUNIX lerlsof 5 8.0.0 i386 x86at Caldera UNIX_SVR5
$


>
> 			regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
>       joining column's datatypes do not match
>



-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 972-414-9812                 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Thu, 13 May 2004 20:42:26 -0500
Larry Rosenman <ler@lerctr.org>
Re: [HACKERS] threads stuff/UnixWare 
Larry Rosenman <ler@lerctr.org> writes:
> Reply from SCO:

> Indeed.  For "inf", "infinity", and "nan", but not
> "nan(digits)", the pointer is left at the trailing
> matched character instead of the next.

> Moreover, checking our source history, it has been
> broken this way for nearly 12 years.  Couldn't you
> folks have noticed this bug a little sooner!?  :-)

Doesn't give one a warm feeling for the average level of error checking
in Unix programs, does it?

> I gather from this that it will be fixed in the first maint packs
> for 7.1.4.

Good.  I'd say we just leave it for that then.

>    Is there some way we can work around this?

I don't want to, because it would compromise the error checking.
For instance, if we hack the code to accept this behavior, then
it would also accept "NaNN" as soon as SCO fixes their bug.

The regression tests exist to discover platform bugs as well as
Postgres bugs.  In this case, I think having them fail on unpatched
SCO platforms is exactly what should happen.

If you want, you can send in a docs patch for FAQ_SCO to give
people a clue about it.

			regards, tom lane

Fri, 14 May 2004 09:41:58 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] threads stuff/UnixWare 
--On Friday, May 14, 2004 09:41:58 -0400 Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Larry Rosenman <ler@lerctr.org> writes:
>> Reply from SCO:
>
>> Indeed.  For "inf", "infinity", and "nan", but not
>> "nan(digits)", the pointer is left at the trailing
>> matched character instead of the next.
>
>> Moreover, checking our source history, it has been
>> broken this way for nearly 12 years.  Couldn't you
>> folks have noticed this bug a little sooner!?  :-)
>
> Doesn't give one a warm feeling for the average level of error checking
> in Unix programs, does it?

nope....


>
>> I gather from this that it will be fixed in the first maint packs
>> for 7.1.4.
>
> Good.  I'd say we just leave it for that then.
>

Ok, but see below.


>>    Is there some way we can work around this?
>
> I don't want to, because it would compromise the error checking.
> For instance, if we hack the code to accept this behavior, then
> it would also accept "NaNN" as soon as SCO fixes their bug.

Won't this change behaviour for

select 'NaN'::float8

etc such that Applications might fail?


>
> The regression tests exist to discover platform bugs as well as
> Postgres bugs.  In this case, I think having them fail on unpatched
> SCO platforms is exactly what should happen.


>
> If you want, you can send in a docs patch for FAQ_SCO to give
> people a clue about it.

OK. See above comment, etc.


>
> 			regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
>



-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 972-414-9812                 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Fri, 14 May 2004 08:52:36 -0500
Larry Rosenman <ler@lerctr.org>
Re: [HACKERS] threads stuff/UnixWare 