Re: [PATCHES] mingw configure failure detection

2004-05-13 Thread Andrew Dunstan
The patch as applied is totally broken - the tests have to be run by config.status after it has actually tried to make the links, which is why I used AC_CONFIG_COMMANDS. cheers andrew Bruce Momjian wrote: Adjusted attached patch applied. Thanks. I didn't change 'test -e' because 'test -h' d

Re: [PATCHES] ANALYZE patch for review

2004-05-13 Thread Mark Cave-Ayland
Hi Tom, Did you manage to find a spare moment over the past week to check the revised ANALYZE patch I posted to the list? Is there any more work that needs to be done to it before it can applied to CVS? TIA, Mark. --- Mark Cave-Ayland Webbased Ltd. Tamar Science Park Derriford Plymouth PL6 8B

Re: [PATCHES] SetDataBaseName

2004-05-13 Thread Tom Lane
"Mahesh Swamy" <[EMAIL PROTECTED]> writes: > We were wondering is there any particular reason why this function > (SetDataBaseName) was taken out? Evidently because the variable it sets doesn't exist anymore. I cannot think of any valid reason for an extension to have been messing with that varia

Re: [PATCHES] mingw configure failure detection

2004-05-13 Thread Peter Eisentraut
Andrew Dunstan wrote: > The patch as applied is totally broken - the tests have to be run by > config.status after it has actually tried to make the links, which is > why I used AC_CONFIG_COMMANDS. Additional note: Instead of listing the files explicitly, just use $CONFIG_LINKS, which contains th

Re: [PATCHES] mingw configure failure detection

2004-05-13 Thread Andrew Dunstan
Peter Eisentraut wrote: Andrew Dunstan wrote: The patch as applied is totally broken - the tests have to be run by config.status after it has actually tried to make the links, which is why I used AC_CONFIG_COMMANDS. Additional note: Instead of listing the files explicitly, just use $CONFI

[PATCHES] Reorganize backend handling of executable names

2004-05-13 Thread Bruce Momjian
This applied patch reorganizes the backend code to more cleanly manage executable names and backend startup. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Chri

Re: [PATCHES] mingw configure failure detection

2004-05-13 Thread Bruce Momjian
Andrew Dunstan wrote: > Peter Eisentraut wrote: > > >Andrew Dunstan wrote: > > > > > >>The patch as applied is totally broken - the tests have to be run by > >>config.status after it has actually tried to make the links, which is > >>why I used AC_CONFIG_COMMANDS. > >> > >> > > > >Additional

Re: [PATCHES] [HACKERS] threads stuff/UnixWare

2004-05-13 Thread Bruce Momjian
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 threadin

Re: [PATCHES] [HACKERS] threads stuff/UnixWare

2004-05-13 Thread Larry Rosenman
--On Thursday, May 13, 2004 19:06:15 -0400 Bruce Momjian <[EMAIL PROTECTED]> 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 st

Re: [PATCHES] [HACKERS] threads stuff/UnixWare

2004-05-13 Thread Tom Lane
Bruce Momjian <[EMAIL PROTECTED]> writes: > *** src/Makefile.global.in11 May 2004 21:57:14 - 1.182 > --- src/Makefile.global.in13 May 2004 23:03:12 - > *** > *** 177,182 > --- 177,188 > CFLAGS += -Wall -Wmissing-prototypes -Wmissing-declarations > en

Re: [PATCHES] [HACKERS] threads stuff/UnixWare

2004-05-13 Thread Larry Rosenman
--On Thursday, May 13, 2004 19:46:00 -0400 Tom Lane <[EMAIL PROTECTED]> wrote: Bruce Momjian <[EMAIL PROTECTED]> writes: *** src/Makefile.global.in 11 May 2004 21:57:14 - 1.182 --- src/Makefile.global.in 13 May 2004 23:03:12 - *** *** 177,182 --- 177,188

Re: [PATCHES] [HACKERS] threads stuff/UnixWare

2004-05-13 Thread Bruce Momjian
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > *** src/Makefile.global.in 11 May 2004 21:57:14 - 1.182 > > --- src/Makefile.global.in 13 May 2004 23:03:12 - > > *** > > *** 177,182 > > --- 177,188 > > CFLAGS += -Wall -Wmissing-prototypes -Wm

Re: [PATCHES] [HACKERS] threads stuff/UnixWare

2004-05-13 Thread Bruce Momjian
\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

Re: [PATCHES] [HACKERS] threads stuff/UnixWare

2004-05-13 Thread Tom Lane
Bruce Momjian <[EMAIL PROTECTED]> 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 makefil

Re: [PATCHES] [HACKERS] threads stuff/UnixWare

2004-05-13 Thread Larry Rosenman
--On Thursday, May 13, 2004 20:03:24 -0400 Bruce Momjian <[EMAIL PROTECTED]> wrote: Tom Lane wrote: Bruce Momjian <[EMAIL PROTECTED]> 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 > templat

Re: [PATCHES] [HACKERS] threads stuff/UnixWare

2004-05-13 Thread Bruce Momjian
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> 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 templat

Re: [PATCHES] SetDataBaseName

2004-05-13 Thread Mahesh Swamy
Hi Tom, During bootstrap mode, when running initdb, the dabasename template1 is passed in. 741 seems to handle this without using the global variable DatabaseName (which is used in 7.3.3). Our extention still relies on that global variable. So how does 7.4.1 find the database name during bootstra

Re: [PATCHES] [HACKERS] threads stuff/UnixWare

2004-05-13 Thread Bruce Momjian
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 > <[EMAIL PROTECTED]> wrote: > > > Tom Lane wrote: >

Re: [PATCHES] [HACKERS] threads stuff/UnixWare

2004-05-13 Thread Larry Rosenman
--On Thursday, May 13, 2004 20:11:45 -0400 Bruce Momjian <[EMAIL PROTECTED]> 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 w

[PATCHES] FAQ_SCO update for --enable-thread-safety and some other stuff

2004-05-13 Thread Larry Rosenman
$ cvs diff -u FAQ_SCO Index: FAQ_SCO === RCS file: /projects/cvsroot/pgsql-server/doc/FAQ_SCO,v retrieving revision 1.9 diff -u -r1.9 FAQ_SCO --- FAQ_SCO 8 Nov 2002 16:49:15 - 1.9 +++ FAQ_SCO 14 May 2004 00:23:35 -000

Re: [PATCHES] [HACKERS] threads stuff/UnixWare

2004-05-13 Thread Tom Lane
Larry Rosenman <[EMAIL PROTECTED]> 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?

Re: [PATCHES] SetDataBaseName

2004-05-13 Thread Tom Lane
"Mahesh Swamy" <[EMAIL PROTECTED]> writes: > So how does 7.4.1 find the database name during bootstrap mode? I don't think we do. We only really care about the database OID. regards, tom lane ---(end of broadcast)--- TIP 1:

Re: [PATCHES] [HACKERS] threads stuff/UnixWare

2004-05-13 Thread Larry Rosenman
--On Thursday, May 13, 2004 20:49:28 -0400 Tom Lane <[EMAIL PROTECTED]> wrote: Larry Rosenman <[EMAIL PROTECTED]> 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

Re: [PATCHES] [HACKERS] threads stuff/UnixWare

2004-05-13 Thread Tom Lane
Larry Rosenman <[EMAIL PROTECTED]> 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

Re: [PATCHES] [HACKERS] threads stuff/UnixWare

2004-05-13 Thread Larry Rosenman
--On Thursday, May 13, 2004 21:14:40 -0400 Tom Lane <[EMAIL PROTECTED]> wrote: Larry Rosenman <[EMAIL PROTECTED]> 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

Re: [PATCHES] [HACKERS] threads stuff/UnixWare

2004-05-13 Thread Tom Lane
Larry Rosenman <[EMAIL PROTECTED]> 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 ---(end of broadcast)

Re: [PATCHES] [HACKERS] threads stuff/UnixWare

2004-05-13 Thread Larry Rosenman
--On Thursday, May 13, 2004 21:26:50 -0400 Tom Lane <[EMAIL PROTECTED]> wrote: Larry Rosenman <[EMAIL PROTECTED]> 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, poi

Re: [PATCHES] [HACKERS] threads stuff/UnixWare

2004-05-13 Thread Tom Lane
Larry Rosenman <[EMAIL PROTECTED]> 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. No

Re: [PATCHES] [HACKERS] threads stuff/UnixWare

2004-05-13 Thread Larry Rosenman
--On Thursday, May 13, 2004 21:35:43 -0400 Tom Lane <[EMAIL PROTECTED]> wrote: Larry Rosenman <[EMAIL PROTECTED]> 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