Thread: (: JDBC+(Sun ~3:pm MST) CVS :) -also question about regression tests

JDBC works
postgres works

I is happy :)
[wasn't posted so I figure I'd post]

Runs very nicely under egcs-2.91.06 FWIW...
[about 3-5 times faster than before ... though that could be postgres
improvements - and probably is]

platform : linux  (I'm not posting kernel version! it doesn't matter!! :)
    egcs-2.91.06    (gcc-2.8.0 with haifa scheduler + other updates)
    glibc-2.0.5c    from RedHat-5.0 distrib - should be stable
            [but with full crypt, locale]

But : Here's output from regression tests:
Is there anything wrong with the failed tests?  (is it known?)

=============== Notes...                              =================
postmaster must already be running for the regression tests to succeed.
The time zone is now set to PST8PDT explicitly by this regression test
 client frontend. Please report any apparent problems to
   ports@postgresql.org
See regress/README for more information.

=============== destroying old regression database... =================
ERROR:  destroydb: database regression does not exist.
destroydb: database destroy failed on regression.
=============== creating new regression database...   =================
=============== running regression queries...         =================
boolean .. ok
char .. ok
char2 .. ok
char4 .. ok
char8 .. ok
char16 .. ok
varchar .. ok
text .. ok
strings .. failed
int2 .. failed
int4 .. failed
oid .. ok
oidint2 .. failed
oidint4 .. failed
oidname .. ok
float4 .. ok
float8 .. failed
numerology .. ok
point .. ok
lseg .. ok
box .. ok
path .. ok
polygon .. ok
circle .. ok
geometry .. failed
timespan .. failed
datetime .. failed
reltime .. ok
abstime .. ok
tinterval .. ok
horology .. failed
comments .. ok
create_function_1 .. ok
create_type .. ok
create_table .. ok
create_function_2 .. ok
constraints .. ok
triggers .. failed
copy .. ok
create_misc .. ok
create_aggregate .. ok
create_operator .. ok
create_view .. ok
create_index .. ok
sanity_check .. ok
errors .. ok
select .. ok
select_into .. ok
select_distinct .. ok
select_distinct_on .. ok
aggregates .. ok
transactions .. ok
random .. failed
portals .. ok
misc .. ok
arrays .. ok
btree_index .. ok
hash_index .. ok
select_views .. failed
alter_table .. ok
portals_p2 .. ok

>
> JDBC works
> postgres works
>
> I is happy :)
> [wasn't posted so I figure I'd post]
>
> Runs very nicely under egcs-2.91.06 FWIW...
> [about 3-5 times faster than before ... though that could be postgres
> improvements - and probably is]

You said 3-5 TIMES faster?  Than 6.2.1, or last weeks source tree?  Can
you give some figures.  I am curious.

>
> platform : linux  (I'm not posting kernel version! it doesn't matter!! :)
>     egcs-2.91.06    (gcc-2.8.0 with haifa scheduler + other updates)
>     glibc-2.0.5c    from RedHat-5.0 distrib - should be stable
>             [but with full crypt, locale]
>
> But : Here's output from regression tests:
> Is there anything wrong with the failed tests?  (is it known?)

I get the same regression output.  checkresults shows you the problems,
and it mostly error message words or rounding.

>
> =============== Notes...                              =================
> postmaster must already be running for the regression tests to succeed.
> The time zone is now set to PST8PDT explicitly by this regression test
>  client frontend. Please report any apparent problems to
>    ports@postgresql.org
> See regress/README for more information.
>
> =============== destroying old regression database... =================
> ERROR:  destroydb: database regression does not exist.
> destroydb: database destroy failed on regression.
> =============== creating new regression database...   =================
> =============== running regression queries...         =================
> boolean .. ok
> char .. ok
> char2 .. ok
> char4 .. ok
> char8 .. ok
> char16 .. ok
> varchar .. ok
> text .. ok
> strings .. failed
> int2 .. failed
> int4 .. failed
> oid .. ok
> oidint2 .. failed
> oidint4 .. failed
> oidname .. ok
> float4 .. ok
> float8 .. failed
> numerology .. ok
> point .. ok
> lseg .. ok
> box .. ok
> path .. ok
> polygon .. ok
> circle .. ok
> geometry .. failed
> timespan .. failed
> datetime .. failed
> reltime .. ok
> abstime .. ok
> tinterval .. ok
> horology .. failed
> comments .. ok
> create_function_1 .. ok
> create_type .. ok
> create_table .. ok
> create_function_2 .. ok
> constraints .. ok
> triggers .. failed
> copy .. ok
> create_misc .. ok
> create_aggregate .. ok
> create_operator .. ok
> create_view .. ok
> create_index .. ok
> sanity_check .. ok
> errors .. ok
> select .. ok
> select_into .. ok
> select_distinct .. ok
> select_distinct_on .. ok
> aggregates .. ok
> transactions .. ok
> random .. failed
> portals .. ok
> misc .. ok
> arrays .. ok
> btree_index .. ok
> hash_index .. ok
> select_views .. failed
> alter_table .. ok
> portals_p2 .. ok
>
>
>
>


--
Bruce Momjian
maillist@candle.pha.pa.us

> > JDBC works
> > postgres works
> > platform : linux  (I'm not posting kernel version! it doesn't matter!! :)
> >       egcs-2.91.06    (gcc-2.8.0 with haifa scheduler + other updates)
> >       glibc-2.0.5c    from RedHat-5.0 distrib - should be stable
> >                       [but with full crypt, locale]
> >
> > But : Here's output from regression tests:
> > Is there anything wrong with the failed tests?  (is it known?)
>
> I get the same regression output.  checkresults shows you the problems,
> and it mostly error message words or rounding.

Hmm. A linux box is used to generate the expected results, so we need to be
more careful here. I suspect that you have date/time trouble reported earlier
by (Oliver?? can't find the e-mail, sorry). A few of the math functions in
glibc2.0.x were misbehaving, leading to troubles like '3 hours 59 minutes 60
seconds' rather than '4 hours' in timespan output.

That person submitted patches, but they were pretty specific to the glibc2
problems. Of course, I've already got some ugly code in there because Solaris
had some similar broken math, so perhaps we should figure out how to extract
all of the busted code into the port-specific files?

                                                        - Tom

On Sun, 1 Feb 1998, Bruce Momjian wrote:

> >
> > JDBC works
> > postgres works
> >
> > I is happy :)
> > [wasn't posted so I figure I'd post]
> >
> > Runs very nicely under egcs-2.91.06 FWIW...
> > [about 3-5 times faster than before ... though that could be postgres
> > improvements - and probably is]
>
> You said 3-5 TIMES faster?  Than 6.2.1, or last weeks source tree?  Can
> you give some figures.  I am curious.

unfortunately I can't give older times...  I could make current times
though if I knew how.  Postgres just _FLEW_ rebuilding the company
database *grin*.
This is Sunday CVS versus Friday CVS + egcs+haifa vs gcc-2.7.2.1

suspect it's an egcs thing mostly - though current postgres is faster than
6.2.1.

I've been following the CVS the entire time - except for about a 1 month
block ending last week :)

I'm just happy it's still up, operational, and fast :)
[egcs in the past usually crashed during the compile... and sometimes
produced unstable results.  so I used gcc-2.7.2.1 as a rule.  Just out of
curiousity I compiled using egcs+haifa which I'd just compiled+installed
and postgres ran beautifully :]
... No special command-line options though BTW.
And I've been glibc-2 since last march.

G'day, eh? :)
    - Teunis

On Mon, 2 Feb 1998, teunis wrote:

> On Sun, 1 Feb 1998, Bruce Momjian wrote:
>
> > >
> > > JDBC works
> > > postgres works
> > >
> > > I is happy :)
> > > [wasn't posted so I figure I'd post]
> > >
> > > Runs very nicely under egcs-2.91.06 FWIW...
> > > [about 3-5 times faster than before ... though that could be postgres
> > > improvements - and probably is]
> >
> > You said 3-5 TIMES faster?  Than 6.2.1, or last weeks source tree?  Can
> > you give some figures.  I am curious.
>
> unfortunately I can't give older times...  I could make current times
> though if I knew how.  Postgres just _FLEW_ rebuilding the company
> database *grin*.

    Well, that gives us something figurative to work with *grin*  How
big is this company database?  What do you mean by FLEW rebuilding?
Number of records?  Disk space used up?  Details man, details :)

On Mon, 2 Feb 1998, Thomas G. Lockhart wrote:

> > > JDBC works
> > > postgres works
> > > platform : linux  (I'm not posting kernel version! it doesn't matter!! :)
> > >       egcs-2.91.06    (gcc-2.8.0 with haifa scheduler + other updates)
> > >       glibc-2.0.5c    from RedHat-5.0 distrib - should be stable
> > >                       [but with full crypt, locale]
> > >
> > > But : Here's output from regression tests:
> > > Is there anything wrong with the failed tests?  (is it known?)
> >
> > I get the same regression output.  checkresults shows you the problems,
> > and it mostly error message words or rounding.
>
> Hmm. A linux box is used to generate the expected results, so we need to be
> more careful here. I suspect that you have date/time trouble reported earlier
> by (Oliver?? can't find the e-mail, sorry). A few of the math functions in
> glibc2.0.x were misbehaving, leading to troubles like '3 hours 59 minutes 60
> seconds' rather than '4 hours' in timespan output.
>
> That person submitted patches, but they were pretty specific to the glibc2
> problems. Of course, I've already got some ugly code in there because Solaris
> had some similar broken math, so perhaps we should figure out how to extract
> all of the busted code into the port-specific files?

I'll say it again and again - glibc-2.0 is the _STANDARD_ (actually
reference) platform for Unix.  All Unix.  Not just Linux.
Adopted last year.

If there's any problems with glibc-2 - that is BAD for postgres.  There
HAVE been real bugs with glibc-2 : but they are very rare (thankfully :).

In other words - please fix it! :)
[glibc-2 was adopted by Unix98 IIRC as the reference platform to base all
libc's on.  Sure a nice change to have public/GNU software providing the
specs... :]  (the last time was BSD's telnet/ftp varient - a LONG time ago
IIRC)

G'day, eh? :)
    - Teunis

On Mon, 2 Feb 1998, teunis wrote:

> On Mon, 2 Feb 1998, Thomas G. Lockhart wrote:
>
> > > > JDBC works
> > > > postgres works
> > > > platform : linux  (I'm not posting kernel version! it doesn't matter!! :)
> > > >       egcs-2.91.06    (gcc-2.8.0 with haifa scheduler + other updates)
> > > >       glibc-2.0.5c    from RedHat-5.0 distrib - should be stable
> > > >                       [but with full crypt, locale]
> > > >
> > > > But : Here's output from regression tests:
> > > > Is there anything wrong with the failed tests?  (is it known?)
> > >
> > > I get the same regression output.  checkresults shows you the problems,
> > > and it mostly error message words or rounding.
> >
> > Hmm. A linux box is used to generate the expected results, so we need to be
> > more careful here. I suspect that you have date/time trouble reported earlier
> > by (Oliver?? can't find the e-mail, sorry). A few of the math functions in
> > glibc2.0.x were misbehaving, leading to troubles like '3 hours 59 minutes 60
> > seconds' rather than '4 hours' in timespan output.
> >
> > That person submitted patches, but they were pretty specific to the glibc2
> > problems. Of course, I've already got some ugly code in there because Solaris
> > had some similar broken math, so perhaps we should figure out how to extract
> > all of the busted code into the port-specific files?
>
> I'll say it again and again - glibc-2.0 is the _STANDARD_ (actually
> reference) platform for Unix.  All Unix.  Not just Linux.
> Adopted last year.

    And...how many Unix (other then Linux) are *actually* using it?
Any idea on how we can test whether it is being used or not?

    The "let's break all ports except Linux because the rest don't
follow a new standard" argument just don't hold water for those not using
Linux :)

> > > > JDBC works
> > > > postgres works
> > > > platform : linux  (I'm not posting kernel version! it doesn't matter!! :)
> > > >       egcs-2.91.06    (gcc-2.8.0 with haifa scheduler + other updates)
> > > >       glibc-2.0.5c    from RedHat-5.0 distrib - should be stable
> > > >                       [but with full crypt, locale]

> > Hmm. A linux box is used to generate the expected results, so we need to be
> > more careful here. I suspect that you have date/time trouble reported earlier
> > by (Oliver?? can't find the e-mail, sorry). A few of the math functions in
> > glibc2.0.x were misbehaving, leading to troubles like '3 hours 59 minutes 60
> > seconds' rather than '4 hours' in timespan output.
> >
> > That person submitted patches, but they were pretty specific to the glibc2
> > problems. Of course, I've already got some ugly code in there because Solaris
> > had some similar broken math, so perhaps we should figure out how to extract
> > all of the busted code into the port-specific files?
>
> I'll say it again and again - glibc-2.0 is the _STANDARD_ (actually
> reference) platform for Unix.  All Unix.  Not just Linux.
> Adopted last year.
>
> If there's any problems with glibc-2 - that is BAD for postgres.  There
> HAVE been real bugs with glibc-2 : but they are very rare (thankfully :).

Great. Then when they get this bug out it will work on Postgres without changes.
I'll wait. If you want to pursue it on the glibc2 side and give them a patch
perhaps they will fix the bug faster.

The nature of the bug (if I recall; this has been going for a while now) is that
there are rounding behaviors in the math library which are at odds with other Unix
systems and with the *documented behaviors of the routines in question*. By my
standards, that counts as a bug. Happy to consider workarounds, but the patches
should be generic and testable, through configure, so that when glibc2 starts
behaving correctly there will be no need to hunt through the backend to find all
the kludge bug fixes.

<Whew, I feel better now>

The other good possibility is for Oliver to develop a patch kit (he has done so
already) which we can include in the v6.3 distribution to be applied only to
linux/glibc2. When the beta settles down perhaps Oliver can generate a new patch
kit which we can include?

btw, I'm running the same systems you are; RH5.0 is in the mail...

                                                      - Tom

> In other words - please fix it! :)
> [glibc-2 was adopted by Unix98 IIRC as the reference platform to base all
> libc's on.  Sure a nice change to have public/GNU software providing the
> specs... :]  (the last time was BSD's telnet/ftp varient - a LONG time ago
> IIRC)

On Mon, 2 Feb 1998, The Hermit Hacker wrote:

> On Mon, 2 Feb 1998, teunis wrote:
>
> > > > Runs very nicely under egcs-2.91.06 FWIW...
> > > > [about 3-5 times faster than before ... though that could be postgres
> > > > improvements - and probably is]
> > >
> > > You said 3-5 TIMES faster?  Than 6.2.1, or last weeks source tree?  Can
> > > you give some figures.  I am curious.
> >
> > unfortunately I can't give older times...  I could make current times
> > though if I knew how.  Postgres just _FLEW_ rebuilding the company
> > database *grin*.
>
>     Well, that gives us something figurative to work with *grin*  How
> big is this company database?  What do you mean by FLEW rebuilding?
> Number of records?  Disk space used up?  Details man, details :)

*heh*
psql simply flew past - it's not a very big database (just about no real
data - but about 40 complex tables)....

I used to (last Friday, say :) be able to watch each table be created...
now it's almost instant.  (~1/2 second per table creation before).

Disk space?  about 1M - not big.  yet.

On the flip side, this database will be holding all of the company sales
records / calls / customer accounting / etc.... as soon as the client
(Java) software is stable *grin*...
.. Also planning on selling the Java package - and doing installs of
Postgres/Linux on each one *grin* when possible.  But I'm also going to
have to be windows/some database compatible and I'm not looking foreward
to that *deep sigh*.

G'day, eh? :)
    - Teunis

> > I'll say it again and again - glibc-2.0 is the _STANDARD_ (actually
> > reference) platform for Unix.  All Unix.  Not just Linux.
> > Adopted last year.
>
>     And...how many Unix (other then Linux) are *actually* using it?
> Any idea on how we can test whether it is being used or not?

AFAIK some BSD's are now using it - but I am probably wrong.  I gave up on
BSD in '92.

>     The "let's break all ports except Linux because the rest don't
> follow a new standard" argument just don't hold water for those not using
> Linux :)

There's no reason to break anything with this...  This is a way of
detecting it (there are others IIRC).

#if (__GLIBC__ >= 2)
[glibc-2 stuff]
#endif

for a complicated varient.

Most of the minor nit-picks involve actually mean going into source and
fixing it.  (ie - not really port-related fixes).

That and #undef HAVE_INT_TIMEZONE in os/linux.h for glibc-2...  as that's
autodetected (and invalid).  Detecting HAVE_SIGSETJMP would be nice to as
it really IS a function in glibc (just remapped via a #define).

AFAIK gnu's libc's are not used on just linux.  So making it a linux-only
thing would be almost as bad as not fixing it in the first place... *g*
(not trying to be rude - personally I've found that the database works
well enough regardless of the regression tests :)

G'day, eh? :)
    - Teunis

>
> Great. Then when they get this bug out it will work on Postgres without changes.
> I'll wait. If you want to pursue it on the glibc2 side and give them a patch
> perhaps they will fix the bug faster.

Okay - I'll bite.  Where's the bug?
What part of the libs?
What function?
What behaviour?

And you're right - the documentation rules where functions are defined.
(And the documents are Unix98 - not any particular OS....  though BSD
should be a good reference for most :) [but not all]

If there's a real problem there's a real path to tell the people how to
fix it :)
[and I have full gcc/egcs/glibc/... source on my computer so can look it
up...]

G'day, eh? :)
    - Teunis

On Mon, 2 Feb 1998, teunis wrote:

> > > I'll say it again and again - glibc-2.0 is the _STANDARD_ (actually
> > > reference) platform for Unix.  All Unix.  Not just Linux.
> > > Adopted last year.
> >
> >     And...how many Unix (other then Linux) are *actually* using it?
> > Any idea on how we can test whether it is being used or not?
>
> AFAIK some BSD's are now using it - but I am probably wrong.  I gave up on
> BSD in '92.

    Geez, about the time I gave up on Linux and converted to *BSD
*grin*

> There's no reason to break anything with this...  This is a way of
> detecting it (there are others IIRC).
>
> #if (__GLIBC__ >= 2)
> [glibc-2 stuff]
> #endif
>
> for a complicated varient.

    I personally feel that this would be an acceptable way of fixing
the bugs...again, this is compiler defined, so its pretty transparent to
the 'end-user'...do you want to supply patches that does this?  Thomas,
does this work for you as well?

> That and #undef HAVE_INT_TIMEZONE in os/linux.h for glibc-2...  as that's
> autodetected (and invalid).  Detecting HAVE_SIGSETJMP would be nice to as
> it really IS a function in glibc (just remapped via a #define).

    Patch for this?  I'd rather see a patch of what you'd like to
review then to blindly go around and "fix" what I can't directly test. :)

> AFAIK gnu's libc's are not used on just linux.  So making it a linux-only
> thing would be almost as bad as not fixing it in the first place... *g*
> (not trying to be rude - personally I've found that the database works
> well enough regardless of the regression tests :)

    It would be worse, IMHO...just look at the 'wine' project...such
good potential, but they core developers feel that supporting Linux-only
is the way to go...so they keep bringing in these really great features
... that work *only* under Linux.  Then, they release a new beta and find
out that nobody else can use it anymore :(

    At least 3 out of 4 of the core developers here are *BSD, so we
offset the Linux-camp very well *grin*  *wave to Thomas*

On Mon, 2 Feb 1998, The Hermit Hacker wrote:

> On Mon, 2 Feb 1998, teunis wrote:
>
> > > > I'll say it again and again - glibc-2.0 is the _STANDARD_ (actually
> > > > reference) platform for Unix.  All Unix.  Not just Linux.
> > > > Adopted last year.
> > >
> > >     And...how many Unix (other then Linux) are *actually* using it?
> > > Any idea on how we can test whether it is being used or not?
> >
> > AFAIK some BSD's are now using it - but I am probably wrong.  I gave up on
> > BSD in '92.
>
>     Geez, about the time I gave up on Linux and converted to *BSD
> *grin*

Awww - I only gave up on BSD 'cause it had no sound *grin*....  So I'm
biased.  [and I've since grown to love Linux's many quirks so I'm never
going back... but each to their own, yes? :]

> > There's no reason to break anything with this...  This is a way of
> > detecting it (there are others IIRC).
> >
> > #if (__GLIBC__ >= 2)
> > [glibc-2 stuff]
> > #endif
> >
> > for a complicated varient.
>
>     I personally feel that this would be an acceptable way of fixing
> the bugs...again, this is compiler defined, so its pretty transparent to
> the 'end-user'...do you want to supply patches that does this?  Thomas,
> does this work for you as well?

I'll work on it (I've attached a modified os.h to the end - this is so it
will work at all).  Don't know how much time I'll have though....

[clipa]
> > AFAIK gnu's libc's are not used on just linux.  So making it a linux-only
> > thing would be almost as bad as not fixing it in the first place... *g*
> > (not trying to be rude - personally I've found that the database works
> > well enough regardless of the regression tests :)
>
>     It would be worse, IMHO...just look at the 'wine' project...such
> good potential, but they core developers feel that supporting Linux-only
> is the way to go...so they keep bringing in these really great features
> ... that work *only* under Linux.  Then, they release a new beta and find
> out that nobody else can use it anymore :(
>
>     At least 3 out of 4 of the core developers here are *BSD, so we
> offset the Linux-camp very well *grin*  *wave to Thomas*

*grin* - as long as linux is supported at all I'm happy :)
There's no real special features there that would benefit anything other
than a really low-level system (eg. Wine, Dosemu) anyways...

(aside: I also work on GGI (formerly linux-GGI) a [largely] system-neutral
graphics toolkit.  Was originally modified kernel linux-only but now works
on SGI O/2, AIX, and others...  under X, ascii (libaa), svgalib, and still
supporting the linux-native (KGI) drivers if under linux... :)
That crew is 100% linux-only but people had access to other hardware and
ported it....  soon people will try to port the kernel level to FreeBSD :)

[linux.h - canna remember where it is... but here's an updated version.
I'd prefer this stuff be in config.h or better handled by configure, but
that's life]

/* __USE_POSIX, __USE_BSD, and __USE_BSD_SIGNAL used to be defined either
   here or with -D compile options, but __ macros should be set and used by C
   library macros, not Postgres code.  __USE_POSIX is set by features.h,
   __USE_BSD is set by bsd/signal.h, and __USE_BSD_SIGNAL appears not to
   be used.
*/
#define JMP_BUF
#define USE_POSIX_TIME
#define USE_POSIX_SIGNALS
#define NEED_I386_TAS_ASM
#define HAS_TEST_AND_SET

#if defined(PPC)
typedef unsigned int slock_t;
#elif defined(__alpha__)
typedef long int slock_t;
#else
typedef unsigned char slock_t;
#endif

#if (__GLIBC__ >= 2)
#ifdef HAVE_INT_TIMEZONE
#undef HAVE_INT_TIMEZONE
#endif
/* currently undefined as I (teunis@computersupportcentre.com) have not
   checked this yet */
/* #define HAVE_SIGSETJMP 1 */
#endif

#if defined(PPC)
#undef NEED_I386_TAS_ASM
#undef HAVE_INT_TIMEZONE
#endif

#if defined(sparc)
#undef NEED_I386_TAS_ASM
#endif

#if defined(__alpha__)
#undef NEED_I386_TAS_ASM
#endif

On Mon, 2 Feb 1998, teunis wrote:

> >     Geez, about the time I gave up on Linux and converted to *BSD
> > *grin*
>
> Awww - I only gave up on BSD 'cause it had no sound *grin*....  So I'm
> biased.  [and I've since grown to love Linux's many quirks so I'm never
> going back... but each to their own, yes? :]

    Agreed...I'm just expected to maintain this anti-Linux
attitude *grin*

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org

> > There's no reason to break anything with this...  This is a way of
> > detecting it (there are others IIRC).
> >
> > #if (__GLIBC__ >= 2)
> > [glibc-2 stuff]
> > #endif
> >
> > for a complicated variant.
>
>         I personally feel that this would be an acceptable way of fixing
> the bugs...again, this is compiler defined, so its pretty transparent to
> the 'end-user'...do you want to supply patches that does this?  Thomas,
> does this work for you as well?

This is the nature of the patch Oliver developed which I'll bet works just
great. However, the patch is on top of kludge code to get Solaris to work one
or two releases ago. I'd rather back those changes out, and get #ifdef Solaris
as well as #ifdef _GLIBC_ code blocks, or even better put these in the
port-specific code.

I'd also like to not have to watch this too closely for v6.3, since I should be
swamped with docs, regression testing, and perhaps contributing to subselects.

If we do apply the glibc2 patches, then I'd like help from someone running
Solaris to clean things up for v6.4.

> That and #undef HAVE_INT_TIMEZONE in os/linux.h for glibc-2...  as that's

> > autodetected (and invalid).  Detecting HAVE_SIGSETJMP would be nice to as
> > it really IS a function in glibc (just remapped via a #define).

So, we kludge both HAVE_INT_TIMEZONE and HAVE_SIGSETJMP in config.h.in by
bracketing them with #if (_GLIBC_ >= 2) ? I suspect that the RH5.0 distribution
of Postgres has broken date and time behavior because HAVE_INT_TIMEZONE is
wrong.

The HAVE_SIGSETJMP problem (which is present in RH4.x also since sigsetjmp() is
defined as a macro, which is explicitly disallowed by the configure test) can
be worked-around by checking for #ifdef sigsetjmp. btw, I've tried running
RH4.2 compiled both ways and noticed no difference in behavior, but I'm not
certain what to look for.

Oh, I forgot; already fixed it because I was tired of the compiler warnings.
Here is the code in bootstrap.c:

/* The test for HAVE_SIGSETJMP fails on Linux 2.0.x because the test
 *  explicitly disallows sigsetjmp being a #define, which is how it
 *  is declared in Linux. So, to avoid compiler warnings about
 *  sigsetjmp() being redefined, let's not redefine unless necessary.
 * - thomas 1997-12-27
 */

#if !defined(HAVE_SIGSETJMP) && !defined(sigsetjmp)
static jmp_buf Warn_restart;
#define sigsetjmp(x,y)  setjmp(x)
#define siglongjmp longjmp

#else
static sigjmp_buf Warn_restart;
#endif

...

>         Patch for this?  I'd rather see a patch of what you'd like to
> review then to blindly go around and "fix" what I can't directly test. :)
>
> > AFAIK gnu's libc's are not used on just linux.  So making it a linux-only
> > thing would be almost as bad as not fixing it in the first place... *g*
> > (not trying to be rude - personally I've found that the database works
> > well enough regardless of the regression tests :)
>
>         It would be worse, IMHO...just look at the 'wine' project...such
> good potential, but they core developers feel that supporting Linux-only
> is the way to go...so they keep bringing in these really great features
> ... that work *only* under Linux.  Then, they release a new beta and find
> out that nobody else can use it anymore :(
>
>         At least 3 out of 4 of the core developers here are *BSD, so we
> offset the Linux-camp very well *grin*  *wave to Thomas*

Sure, takes 3 BSD machines for an even fight *ducks and hits head on desk*

                                         - Tom

On Tue, 3 Feb 1998, Thomas G. Lockhart wrote:

> I'd also like to not have to watch this too closely for v6.3, since I
> should be swamped with docs, regression testing, and perhaps
> contributing to subselects.

    Oops, okay, sorry :(  Agreed, let's look at this *after* v6.3 is
released then

> So, we kludge both HAVE_INT_TIMEZONE and HAVE_SIGSETJMP in config.h.in
> by bracketing them with #if (_GLIBC_ >= 2) ? I suspect that the RH5.0
> distribution of Postgres has broken date and time behavior because
> HAVE_INT_TIMEZONE is wrong.

    I think that I can come up with "cleaner" tests for these in
configure...

> >         At least 3 out of 4 of the core developers here are *BSD, so we
> > offset the Linux-camp very well *grin*  *wave to Thomas*
>
> Sure, takes 3 BSD machines for an even fight *ducks and hits head on desk*

    As I said to a friend of mine the other day, I imagine that Linux
constitutes a good portion of our user base, especially now that RedHat
includes it as standard with their distributions *shrug*  Its not
Microsloth, that's all that counts :)