Обсуждение: More on 6.4 on DEC Alpha + Digital Unix 4.0d + DEC C compiler

Hi.

I've been doing some more tests with the above configuration, and have
noticed the following problems when running the regression tests:

1)    THE REGRESSION TEST FOR FLOAT8 IS BROKEN!!!

Indeed, the "expected" output for the exp() operator ":" is brain damaged.
This is the query at line 197 of expected/float8.out:

QUERY: SELECT '' AS bad, : (f.f1) from FLOAT8_TBL f;

which operates on this table:

QUERY: SELECT '' AS five, FLOAT8_TBL.*;
five|f1
----+--------------------   |0   |1004.3   |-34.84   |1.2345678901234e+200   |1.2345678901234e-200
(5 rows)

As you can see, the query tries to compute exp(1004.3), which should be
out of range (the maximum computable is exp(709.78271289338402)), and 
exp(1.2345678901234e+200), which also should be out of range (but only a
bit ;-). So, the query should fail with an out of range error, as does on
my system ("ERROR:  exp() result is out of range"). However, the
"expected" output is:

bad|            ?column?
---+--------------------  |                   1  |7.39912306090513e-16  |                   0  |                   0  |
                 1
 
(5 rows)

which is clearly incorrect.

2) The tests for char, varchar, select_implicit, select_having and rules
fail when locale is enabled, and pass when locale is disabled. This is due
to character comparisons being case insensitive when locale is enabled. I
don't think this is the correct behaviour. I'd appreciate any hint on
where to look to investigate this further.

3) The int8 type is completely brain damaged on my system. The output from
any select that gets an int8 is '4831823328'. Pointers?

4) The int2 and int4 tests fail due to differences in error messages.
This is innocuous, but annoying. I've seen that some systems have
customized expected results. I am willing to build these customized
results for DU4, if some kind soul wants to instruct me on how to do it.

5) The geometry test fails because of rounding differences on the last
digit. I don't know if this is really a problem and/or how to fix it.

6) The inet test fails, but I haven't looked at it yet.

7) The abstime, tinterval and horology tests fail. It seems to be caused
by incorrect handling of the daylight savings. However, the output seems
to be "less incorrect" than on previous versions.

8) The plpgsql test fails, but I haven't looked at it yet.

Well, this is enough for now. Let me know what you thing about these
problems, and let's see how we can fix them.

-------------------------------------------------------------------
Pedro José Lobo Perea                   Tel:    +34 91 336 78 19
Centro de Cálculo                       Fax:    +34 91 331 92 29
EUIT Telecomunicación - UPM             e-mail: pjlobo@euitt.upm.es

> 1) THE REGRESSION TEST FOR FLOAT8 IS BROKEN!!!
> the "expected" output for the exp() operator ":" is brain damaged.

The reference platform never lies. Better figure out how to break your
machine instead :)

> 2) The tests for char, varchar, select_implicit, select_having and 
> rules fail when locale is enabled, and pass when locale is disabled. 
> This is due to character comparisons being case insensitive when 
> locale is enabled. I don't think this is the correct behaviour. I'd 
> appreciate any hint on where to look to investigate this further.

src/backend/utils/adt/varlena.c

> 3) The int8 type is completely brain damaged on my system. The output 
> from any select that gets an int8 is '4831823328'. Pointers?

It should be easy to fix, since you have a real 64-bit machine. Sorry
I've lost access to my DUnix-4.0 boxes so can't help directly. Look at
what configure decided your int8 setup should be.

> 4) ...
> 5) ...

Both are solved with platform-specific "expected" results (as would the
exp "failure" earlier, though it should be fixed on the reference
platform).

> 7) The abstime, tinterval and horology tests fail. It seems to be 
> caused by incorrect handling of the daylight savings. However, the 
> output seems to be "less incorrect" than on previous versions.

This has always been due to conflicts between the two styles of
date/time support on Unix boxes. Perhaps it isn't being configured
correctly?
                   - Tom

Hi!

On Thu, 19 Nov 1998, Thomas G. Lockhart wrote:
> > 2) The tests for char, varchar, select_implicit, select_having and 
> > rules fail when locale is enabled, and pass when locale is disabled. 
> > This is due to character comparisons being case insensitive when 
> > locale is enabled. I don't think this is the correct behaviour. I'd 
> > appreciate any hint on where to look to investigate this further.
> 
> src/backend/utils/adt/varlena.c
  "character comparisons being case insensitive"? It is a problem in your
locale, not in the comparison code (I hope). There is no such thing as
"case-insensitive strcoll", and I just used strcoll in varlena.c.  The same problem popped up many times among linux
users.Just install
 
correct locale - and all will run well. There are test programs in
src/test/locale, look carefully. If you can - supply test data for your
locale.

(It looks like my messages to pgsql-*@postgresql.org are usually dropped to
floor. If anyone see it - please confirm, send to: phd2@earthling.net. I
have no problems receiving mail from these lists, neither sending to many
other lists I am on).

Oleg.
----  Oleg Broytmann     http://members.tripod.com/~phd2/     phd2@earthling.net          Programmers don't die, they
justGOSUB without RETURN.
 

On Thu, 19 Nov 1998, Oleg Broytmann wrote:

>Hi!
>
>On Thu, 19 Nov 1998, Thomas G. Lockhart wrote:
>> > 2) The tests for char, varchar, select_implicit, select_having and 
>> > rules fail when locale is enabled, and pass when locale is disabled. 
>> > This is due to character comparisons being case insensitive when 
>> > locale is enabled. I don't think this is the correct behaviour. I'd 
>> > appreciate any hint on where to look to investigate this further.
>> 
>> src/backend/utils/adt/varlena.c
>
>   "character comparisons being case insensitive"? It is a problem in your
>locale, not in the comparison code (I hope). There is no such thing as
>"case-insensitive strcoll", and I just used strcoll in varlena.c.
>   The same problem popped up many times among linux users. Just install
>correct locale - and all will run well. There are test programs in
>src/test/locale, look carefully. If you can - supply test data for your
>locale.

Well, after a bit of investigation, now I know where the problem is. When
you do a case sensitive comparison, 'A' is considered "smaller" than 'a'.
Except, of course, if you use Digital's strcoll() (agh!). The comparison
when locale is enabled isn't case insensitive. Simply, the "sensitivity"
is inverted: 'A' is considered *greater* than 'a' (but not equal, as I
first thought). When you use the 'C' locale (that is, no locale), then the
output of strcmp() and strcoll() is the same.

So, this is indeed a Digital Unix problem. I've made the same tests under
FreeBSD, and they work as expected on it.

The next question is what to do now. I will send a message to Digital so
they can fix this bug in future releases, but what do I do in the
meantime? The problem is not dangerous except if you rely on upper-case
letters being ordered before lower-case. I could make a custom "expected"
output so that the regression tests do not fail, or we could simply write
a "README.DigitalUnix" telling the story. Writing a custom strcoll() seems
a bit overkill. What do you think?

>(It looks like my messages to pgsql-*@postgresql.org are usually dropped to
>floor. If anyone see it - please confirm, send to: phd2@earthling.net. I
>have no problems receiving mail from these lists, neither sending to many
>other lists I am on).

Your message made it to the list (I received it two times, one from you
and other from the list).

-------------------------------------------------------------------
Pedro José Lobo Perea                   Tel:    +34 91 336 78 19
Centro de Cálculo                       Fax:    +34 91 331 92 29
EUIT Telecomunicación - UPM             e-mail: pjlobo@euitt.upm.es

Hi!
  Custom strcoll() is best approach, but if don't need it, I think writing
README is enough. Locale tests are not in regressoin test, so everyone
should be happy.  I didn't include locale tests in regression test because:
1) not so many people need locale support
2) anyway there are so many locale problems that regression test will fail
for many testers.  Initially I thought "locale problems" are only in locale data, but your
investigation reveals there are broken locale function out there, too.

On Thu, 19 Nov 1998, Pedro J. Lobo wrote:
> Well, after a bit of investigation, now I know where the problem is. When
> you do a case sensitive comparison, 'A' is considered "smaller" than 'a'.
> Except, of course, if you use Digital's strcoll() (agh!). The comparison
> when locale is enabled isn't case insensitive. Simply, the "sensitivity"
> is inverted: 'A' is considered *greater* than 'a' (but not equal, as I
> first thought). When you use the 'C' locale (that is, no locale), then the
> output of strcmp() and strcoll() is the same.
> 
> So, this is indeed a Digital Unix problem. I've made the same tests under
> FreeBSD, and they work as expected on it.
> 
> The next question is what to do now. I will send a message to Digital so
> they can fix this bug in future releases, but what do I do in the
> meantime? The problem is not dangerous except if you rely on upper-case
> letters being ordered before lower-case. I could make a custom "expected"
> output so that the regression tests do not fail, or we could simply write
> a "README.DigitalUnix" telling the story. Writing a custom strcoll() seems
> a bit overkill. What do you think?

Oleg.
----    Oleg Broytmann  National Research Surgery Centre  http://sun.med.ru/~phd/          Programmers don't die, they
justGOSUB without RETURN.
 

"Thomas G. Lockhart" <lockhart@alumni.caltech.edu> writes:
> "Pedro J. Lobo" <pjlobo@euitt.upm.es> wrote:
>> 1) THE REGRESSION TEST FOR FLOAT8 IS BROKEN!!!
>> the "expected" output for the exp() operator ":" is brain damaged.

> The reference platform never lies.

In this case the reference platform is broken, IMHO.

However, Pedro's not batting 1.000 today either.  The exp() problem
is not overflow but underflow, because a prior query in the float8
test alters the table.  At the point where the test in question
executes, the actual contents of the f1 table are

QUERY: SELECT '' AS five, FLOAT8_TBL.*;
five|f1                   
----+---------------------   |0                       |-34.84                  |-1004.3
|-1.2345678901234e+200  |-1.2345678901234e-200
 
(5 rows)

(taken verbatim from a few lines further down in the "expected" output).

The "expected" output is

QUERY: SELECT '' AS bad, : (f.f1) from FLOAT8_TBL f;
bad|            ?column?
---+--------------------  |                   1  |7.39912306090513e-16  |                   0  |                   0  |
                 1
 
(5 rows)

The first two of these are right, and so is the last one, but the
third and fourth lines represent underflow.  On my machine, when
the result of exp(x) is too small to store as a double, the returned
result is 0 and errno is set to ERANGE --- and this is the behavior
demanded by ANSI C, according to my reference materials.

The implementation of exp() in float.c reads

#ifndef finiteerrno = 0;
#endif*result = (float64data) exp(tmp);
#ifndef finiteif (errno == ERANGE)
#elseif (!finite(*result))
#endif    elog(ERROR, "exp() result is out of range");


Pedro's machine and my machine are obeying the ANSI specification
and producing the "exp() result is out of range" error.

Thomas' machine is evidently following the "ifdef finite" path.
Zero, however, is finite, so his machine is failing to notice the
underflow.

I think we have two possible courses of action here:

1. Follow the ANSI spec and raise an error for exp() underflow.
The ERRNO path is already OK for this, but the other would have
to be made to readif (!finite(*result) || *result == 0.0)
and we'd have to fix the expected regress output.

2. Decide that we are smarter than the ANSI C authors and the
inventors of libm, and that a small exp() result should quietly
underflow to zero.  In that case the ERRNO path would have to readif (errno == ERANGE && *result != 0.0)

I like choice #1 myself.

BTW, while I was at it I took the time to figure out why the
pow() part of the test was failing for me (I was getting zeroes
instead of the expected "pow() result is out of range" error).
Turns out that depending on which HPUX math library version you
use, pow() might fail with EDOM rather than ERANGE for negative
inputs.  I'll change the pow() code to check for either errno
when I get a chance.

>> 7) The abstime, tinterval and horology tests fail. It seems to be 
>> caused by incorrect handling of the daylight savings. However, the 
>> output seems to be "less incorrect" than on previous versions.

On some Unix boxes, the standard time library doesn't know about
daylight savings time for dates before 1970.  This causes localized
discrepancies in the horology results.  I don't see any failures
related to this in abstime or tinterval, however.

tinterval used to have problems with outputs appearing in a bogus
sort order, but that was fixed by some pg_operator patches applied
only a week or so before 6.4 release.  Did you do an initdb after
installing 6.4?  If not then you still have the busted operator
table entries...
        regards, tom lane

On Thu, 19 Nov 1998, Tom Lane wrote:

>"Thomas G. Lockhart" <lockhart@alumni.caltech.edu> writes:
>> "Pedro J. Lobo" <pjlobo@euitt.upm.es> wrote:
>>> 1) THE REGRESSION TEST FOR FLOAT8 IS BROKEN!!!
>>> the "expected" output for the exp() operator ":" is brain damaged.
>
>> The reference platform never lies.
>
>In this case the reference platform is broken, IMHO.
>
>However, Pedro's not batting 1.000 today either.  The exp() problem
>is not overflow but underflow, because a prior query in the float8
>test alters the table.  At the point where the test in question
>executes, the actual contents of the f1 table are
>
>QUERY: SELECT '' AS five, FLOAT8_TBL.*;
>five|f1                   
>----+---------------------
>    |0                    
>    |-34.84               
>    |-1004.3              
>    |-1.2345678901234e+200
>    |-1.2345678901234e-200
>(5 rows)
>
>(taken verbatim from a few lines further down in the "expected" output).

Yep, you are right. I missed the query that multiplies every row in
FLOAT8_TBL by -1.

>1. Follow the ANSI spec and raise an error for exp() underflow.
>The ERRNO path is already OK for this, but the other would have
>to be made to read
>    if (!finite(*result) || *result == 0.0)
>and we'd have to fix the expected regress output.
>
>2. Decide that we are smarter than the ANSI C authors and the
>inventors of libm, and that a small exp() result should quietly
>underflow to zero.  In that case the ERRNO path would have to read
>    if (errno == ERANGE && *result != 0.0)
>
>I like choice #1 myself.

Me too.

>>> 7) The abstime, tinterval and horology tests fail. It seems to be 
>>> caused by incorrect handling of the daylight savings. However, the 
>>> output seems to be "less incorrect" than on previous versions.
>
>On some Unix boxes, the standard time library doesn't know about
>daylight savings time for dates before 1970.  This causes localized
>discrepancies in the horology results.  I don't see any failures
>related to this in abstime or tinterval, however.

The differences appear only when the row(s) correspond to the year 1947,
and the only difference is between "PST" and "PDT" at the end of the date
(don't remember right now which one is the expected).

>tinterval used to have problems with outputs appearing in a bogus
>sort order, but that was fixed by some pg_operator patches applied
>only a week or so before 6.4 release.  Did you do an initdb after
>installing 6.4?  If not then you still have the busted operator
>table entries...

This was not the case. Yes, I did an initdb, and the order of expected and
real results was the same.

After all this, I would say that 6.4 is quite useable in Digital Unix. I
will be moving my production database in the next weeks.

-------------------------------------------------------------------
Pedro José Lobo Perea                   Tel:    +34 91 336 78 19
Centro de Cálculo                       Fax:    +34 91 331 92 29
EUIT Telecomunicación - UPM             e-mail: pjlobo@euitt.upm.es

> > The reference platform never lies.
> In this case the reference platform is broken, IMHO.

Uh, yes. I was hoping that my statement was outrageous enough to be
prima facia absurd. Ha Ha. Pretty funny, eh?

> 1. Follow the ANSI spec and raise an error for exp() underflow.
> The ERRNO path is already OK for this, but the other would have
> to be made to read
>         if (!finite(*result) || *result == 0.0)
> and we'd have to fix the expected regress output.
> 2. Decide that we are smarter than the ANSI C authors and the
> inventors of libm, and that a small exp() result should quietly
> underflow to zero.  In that case the ERRNO path would have to read
>         if (errno == ERANGE && *result != 0.0)
> I like choice #1 myself.

OK, sounds good.

> BTW, while I was at it I took the time to figure out why the
> pow() part of the test was failing for me (I was getting zeroes
> instead of the expected "pow() result is out of range" error).
> Turns out that depending on which HPUX math library version you
> use, pow() might fail with EDOM rather than ERANGE for negative
> inputs.  I'll change the pow() code to check for either errno
> when I get a chance.

Hmm. Any chance of making that HP-specific? It would be a shame to make
every platform test for two values on every calculation...

Regards.
                 - Tom

"Thomas G. Lockhart" <lockhart@alumni.caltech.edu> writes:
>> 1. Follow the ANSI spec and raise an error for exp() underflow.
>> The ERRNO path is already OK for this, but the other would have
>> to be made to read
>> if (!finite(*result) || *result == 0.0)
>> and we'd have to fix the expected regress output.

> OK, sounds good.

OK, I'll do something about it this weekend, unless someone beats me
to it.

>> BTW, while I was at it I took the time to figure out why the
>> pow() part of the test was failing for me (I was getting zeroes
>> instead of the expected "pow() result is out of range" error).
>> Turns out that depending on which HPUX math library version you
>> use, pow() might fail with EDOM rather than ERANGE for negative
>> inputs.  I'll change the pow() code to check for either errno
>> when I get a chance.

> Hmm. Any chance of making that HP-specific? It would be a shame to make
> every platform test for two values on every calculation...

AFAICS, *any* error out of the pow() ought to be treated the same.
So what I was actually planning to do was
errno = 0;result = pow(...);if (errno != 0)    ELOG(...);

which is probably a cycle or two faster than what we have, since
testing against zero is usually a shade cheaper than comparison
to a nonzero constant.

Not that a cycle or three saved or wasted in a pow() function
evaluation is going to be significant, or even measurable ;-)
        regards, tom lane