Thread
-
More on 6.4 on DEC Alpha + Digital Unix 4.0d + DEC C compiler
Pedro J. Lobo <pjlobo@euitt.upm.es> — 1998-11-18T18:08:26Z
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 -
Re: [HACKERS] More on 6.4 on DEC Alpha + Digital Unix 4.0d + DEC C compiler
Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-11-19T03:17:08Z
> 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 -
Re: [HACKERS] More on 6.4 on DEC Alpha + Digital Unix 4.0d + DEC C compiler
Oleg Broytmann <phd@sun.med.ru> — 1998-11-19T09:26:01Z
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 just GOSUB without RETURN. -
Re: [HACKERS] More on 6.4 on DEC Alpha + Digital Unix 4.0d + DEC C compiler
Pedro J. Lobo <pjlobo@euitt.upm.es> — 1998-11-19T10:37:51Z
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
-
Re: [HACKERS] More on 6.4 on DEC Alpha + Digital Unix 4.0d + DEC C compiler
Oleg Broytmann <phd@sun.med.ru> — 1998-11-19T11:10:39Z
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 just GOSUB without RETURN.