Some regression tests are failed RH7.0
Martin Eichhorn (gbibu@bluewin.ch) reports a bug with a severity of 3
The lower the number the more severe it is.
Short Description
Some regression tests are failed RH7.0
Long Description
Installing Postgress on a Red Hat 7.0 Server, some regression test failed (see below). How can i fix this failed queries?
Installed RPMS:
postgresql-7.0.3-2.i386.rpm
postgresql-server-7.0.3-2.i386.rpm
postgresql-devel-7.0.3-2.i386.rpm
postgresql-test-7.0.3-2.i386.rpm
postgresql-python-7.0.3-2.i386.rpm
postgresql-perl-7.0.3-2.i386.rpm
postgresql-jdbc-7.0.3-2.i386.rpm
regression.out:
**********************************************************************
=============== Notes... =================
postmaster must already be running for the regression tests to succeed.
The time zone is set to PST8PDT for these tests by the client frontend.
Please report any apparent problems to ports@postgresql.org
See regress/README for more information.
=============== dropping old regression database... =================
DROP DATABASE
=============== creating new regression database... =================
CREATE DATABASE
=============== installing languages... =================
installing PL/pgSQL .. ok
=============== running regression queries... =================
boolean .. ok
char .. failed
name .. ok
varchar .. failed
text .. ok
int2 .. ok
int4 .. ok
int8 .. failed
oid .. ok
float4 .. ok
float8 .. ok
numeric .. failed
strings .. ok
numerology .. ok
point .. ok
lseg .. ok
box .. ok
path .. ok
polygon .. ok
circle .. ok
interval .. ok
timestamp .. ok
reltime .. ok
tinterval .. ok
inet .. ok
comments .. ok
oidjoins .. ok
type_sanity .. ok
opr_sanity .. ok
abstime .. ok
geometry .. ok
horology .. ok
create_function_1 .. ok
create_type .. ok
create_table .. ok
create_function_2 .. ok
copy .. ok
constraints .. ok
triggers .. ok
create_misc .. ok
create_aggregate .. ok
create_operator .. ok
create_index .. ok
create_view .. ok
sanity_check .. ok
errors .. ok
select .. ok
select_into .. ok
select_distinct .. ok
select_distinct_on .. ok
select_implicit .. failed
select_having .. failed
subselect .. ok
union .. ok
case .. ok
join .. ok
aggregates .. ok
transactions .. ok
random .. ok
portals .. ok
arrays .. ok
btree_index .. ok
hash_index .. ok
misc .. ok
select_views .. failed
alter_table .. ok
portals_p2 .. ok
rules .. ok
foreign_key .. ok
limit .. ok
plpgsql .. ok
temp .. ok
**********************************************************************
Regards Martin
Sample Code
No file was uploaded with this report
pgsql-bugs@postgresql.org writes:
Installing Postgress on a Red Hat 7.0 Server, some regression test
failed (see below). How can i fix this failed queries?
Can't tell a thing from that amount of detail. What's in
regression.diffs?
regards, tom lane
Tom Lane wrote:
pgsql-bugs@postgresql.org writes:
Installing Postgress on a Red Hat 7.0 Server, some regression test
failed (see below). How can i fix this failed queries?Can't tell a thing from that amount of detail. What's in
regression.diffs?
It appears to be the locale deal, Tom. It hits a little too familiar of
a chord (and pattern). If we analyze his regression.diffs, we'll see
lots of collation stuff, as well as money format stuff, I'd wager.
The fix is to set the locale to C. Editing /etc/sysconfig/i18n to set
either LANG=C or LC_ALL=C. Or simply delete it and reboot.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
Lamar Owen <lamar.owen@wgcr.org> writes:
Tom Lane wrote:
Can't tell a thing from that amount of detail. What's in
regression.diffs?
It appears to be the locale deal, Tom. It hits a little too familiar of
a chord (and pattern). If we analyze his regression.diffs, we'll see
lots of collation stuff, as well as money format stuff, I'd wager.
I suspected as much, but didn't want to leap to a conclusion without
seeing the diffs.
The fix is to set the locale to C. Editing /etc/sysconfig/i18n to set
either LANG=C or LC_ALL=C. Or simply delete it and reboot.
Note also that if you change the postmaster's locale you'd better redo
initdb.
BTW, it occurs to me that we don't have anything about locale issues in
the documentation about interpreting the regression tests. Will fix.
regards, tom lane
On Mon, 19 Mar 2001 pgsql-bugs@postgresql.org wrote:
Installing Postgress on a Red Hat 7.0 Server, some regression test
failed (see below). How can i fix this failed queries?
I had similar results here at SuSE. They came from a locale bug in
glibc-2.2 . As a workaround, try to unset LANG or set it to POSIX
before starting the postmaster. AFAIK glibc-2.2.2 will fix this bug.
cu
Reinhard
Tom Lane wrote:
Lamar Owen <lamar.owen@wgcr.org> writes:
Tom Lane wrote:
Can't tell a thing from that amount of detail. What's in
regression.diffs?It appears to be the locale deal, Tom. It hits a little too familiar of
a chord (and pattern). If we analyze his regression.diffs, we'll see
lots of collation stuff, as well as money format stuff, I'd wager.I suspected as much, but didn't want to leap to a conclusion without
seeing the diffs.The fix is to set the locale to C. Editing /etc/sysconfig/i18n to set
either LANG=C or LC_ALL=C. Or simply delete it and reboot.Note also that if you change the postmaster's locale you'd better redo
initdb.BTW, it occurs to me that we don't have anything about locale issues in
the documentation about interpreting the regression tests. Will fix.regards, tom lane
Hi tom lane and lamar owen
Thank your for our fast answer.
1. i will give your more infomation about regression tests
(regression.diff and /etc/sysconfig/i18n see below).
2. Should i change the LANG="en_US" to LANG="C" and send your a new regression
test report?
regards, martin eichhorn
/usr/lib/pgsql/test/regress/regression.diffs:
******************************************************************************************************
*** expected/char.out Tue Jan 4 17:19:34 2000
--- results/char.out Mon Mar 19 14:38:22 2001
***************
*** 62,73 ****
WHERE c.f1 < 'a';
five | f1
------+----
- | A
| 1
| 2
| 3
|
! (5 rows) SELECT '' AS six, c.*
FROM CHAR_TBL c
--- 62,72 ----
WHERE c.f1 < 'a';
five | f1
------+----
| 1
| 2
| 3
|
! (4 rows) SELECT '' AS six, c.*
FROM CHAR_TBL c
***************
*** 75,94 ****
six | f1
-----+----
| a
- | A
| 1
| 2
| 3
|
! (6 rows)
SELECT '' AS one, c.*
FROM CHAR_TBL c
WHERE c.f1 > 'a';
one | f1
-----+----
| c
! (1 row)
SELECT '' AS two, c.*
FROM CHAR_TBL c
--- 74,93 ----
six | f1
-----+----
| a
| 1
| 2
| 3
|
! (5 rows) SELECT '' AS one, c.*
FROM CHAR_TBL c
WHERE c.f1 > 'a';
one | f1
-----+----
+ | A
| c
! (2 rows)
SELECT '' AS two, c.*
FROM CHAR_TBL c
***************
*** 96,103 ****
two | f1
-----+----
| a
| c
! (2 rows)
DROP TABLE CHAR_TBL;
--
--- 95,103 ----
two | f1
-----+----
| a
+ | A
| c
! (3 rows) DROP TABLE CHAR_TBL;
--
----------------------
*** expected/varchar.out Tue Jan 4 17:19:34 2000
--- results/varchar.out Mon Mar 19 14:38:26 2001
***************
*** 50,61 ****
WHERE c.f1 < 'a';
five | f1
------+----
- | A
| 1
| 2
| 3
|
! (5 rows) SELECT '' AS six, c.*
FROM VARCHAR_TBL c
--- 50,60 ----
WHERE c.f1 < 'a';
five | f1
------+----
| 1
| 2
| 3
|
! (4 rows) SELECT '' AS six, c.*
FROM VARCHAR_TBL c
***************
*** 63,82 ****
six | f1
-----+----
| a
- | A
| 1
| 2
| 3
|
! (6 rows)
SELECT '' AS one, c.*
FROM VARCHAR_TBL c
WHERE c.f1 > 'a';
one | f1
-----+----
| c
! (1 row)
SELECT '' AS two, c.*
FROM VARCHAR_TBL c
--- 62,81 ----
six | f1
-----+----
| a
| 1
| 2
| 3
|
! (5 rows) SELECT '' AS one, c.*
FROM VARCHAR_TBL c
WHERE c.f1 > 'a';
one | f1
-----+----
+ | A
| c
! (2 rows)
SELECT '' AS two, c.*
FROM VARCHAR_TBL c
***************
*** 84,91 ****
two | f1
-----+----
| a
| c
! (2 rows)
DROP TABLE VARCHAR_TBL;
--
--- 83,91 ----
two | f1
-----+----
| a
+ | A
| c
! (3 rows) DROP TABLE VARCHAR_TBL;
--
----------------------
*** expected/int8.out Fri Apr 7 21:17:39 2000
--- results/int8.out Mon Mar 19 14:38:30 2001
***************
*** 246,256 ****
SELECT '' AS to_char_13, to_char(q2, 'L9999999999999999.000') FROM
INT8_TBL;
to_char_13 | to_char
------------+------------------------
! | 456.000
! | 4567890123456789.000
! | 123.000
! | 4567890123456789.000
! | -4567890123456789.000
(5 rows) SELECT '' AS to_char_14, to_char(q2, 'FM9999999999999999.999') FROM
INT8_TBL;
--- 246,256 ----
SELECT '' AS to_char_13, to_char(q2, 'L9999999999999999.000') FROM
INT8_TBL;
to_char_13 | to_char
------------+------------------------
! | $ 456.000
! | $ 4567890123456789.000
! | $ 123.000
! | $ 4567890123456789.000
! | $-4567890123456789.000
(5 rows) SELECT '' AS to_char_14, to_char(q2, 'FM9999999999999999.999') FROM
INT8_TBL;
----------------------
*** expected/numeric.out Fri Apr 7 21:17:42 2000
--- results/numeric.out Mon Mar 19 14:40:51 2001
***************
*** 928,943 ****
SELECT '' AS to_char_16, to_char(val,
'L9999999999999999.099999999999999') FROM num_data;
to_char_16 | to_char
------------+------------------------------------
! | .000000000000000
! | .000000000000000
! | -34338492.215397047000000
! | 4.310000000000000
! | 7799461.411900000000000
! | 16397.038491000000000
! | 93901.577630260000000
! | -83028485.000000000000000
! | 74881.000000000000000
! | -24926804.045047420000000
(10 rows) SELECT '' AS to_char_17, to_char(val,
'FM9999999999999999.99999999999999') FROM num_data;
--- 928,943 ----
SELECT '' AS to_char_16, to_char(val,
'L9999999999999999.099999999999999') FROM num_data;
to_char_16 | to_char
------------+------------------------------------
! | $ .000000000000000
! | $ .000000000000000
! | $ -34338492.215397047000000
! | $ 4.310000000000000
! | $ 7799461.411900000000000
! | $ 16397.038491000000000
! | $ 93901.577630260000000
! | $ -83028485.000000000000000
! | $ 74881.000000000000000
! | $ -24926804.045047420000000
(10 rows) SELECT '' AS to_char_17, to_char(val,
'FM9999999999999999.99999999999999') FROM num_data;
----------------------
*** expected/select_implicit.out Thu Jan 6 07:40:54 2000
--- results/select_implicit.out Mon Mar 19 14:44:01 2001
***************
*** 22,32 ****
c | count
----------+-------
AAAA | 2
BBBB | 2
CCCC | 2
XXXX | 1
- bbbb | 1
- cccc | 2
(6 rows) -- w/o existing GROUP BY target using a relation name in GROUP BY clause
--- 22,32 ----
c | count
----------+-------
AAAA | 2
+ bbbb | 1
BBBB | 2
+ cccc | 2
CCCC | 2
XXXX | 1
(6 rows) -- w/o existing GROUP BY target using a relation name in GROUP BY clause
***************
*** 34,44 ****
count
-------
2
2
2
- 1
- 1
2
(6 rows)
-- w/o existing GROUP BY target and w/o existing a different ORDER BY
target
--- 34,44 ----
count
-------
2
+ 1
2
2
2
+ 1
(6 rows) -- w/o existing GROUP BY target and w/o existing a different ORDER BY
target
***************
*** 104,114 ****
c | count
----------+-------
AAAA | 2
BBBB | 2
CCCC | 2
XXXX | 1
- bbbb | 1
- cccc | 2
(6 rows)
-- group using reference number out of range
--- 104,114 ----
c | count
----------+-------
AAAA | 2
+ bbbb | 1
BBBB | 2
+ cccc | 2
CCCC | 2
XXXX | 1
(6 rows)-- group using reference number out of range
----------------------
*** expected/select_having.out Thu Jan 6 07:40:54 2000
--- results/select_having.out Mon Mar 19 14:44:02 2001
***************
*** 34,41 ****
GROUP BY c HAVING count(*) > 2 OR min(a) = max(a);
c | max
----------+-----
- XXXX | 0
bbbb | 5
(2 rows) DROP TABLE test_having;
--- 34,41 ----
GROUP BY c HAVING count(*) > 2 OR min(a) = max(a);
c | max
----------+-----
bbbb | 5
+ XXXX | 0
(2 rows)DROP TABLE test_having;
----------------------
*** expected/select_views.out Sun Jan 9 04:48:37 2000
--- results/select_views.out Mon Mar 19 14:44:51 2001
***************
*** 415,420 ****
--- 415,434 ----
I- 580 | 21
I- 580 | 22
I- 580 | 22
+ I- 580/I-680 Ramp | 2
+ I- 580/I-680 Ramp | 2
+ I- 580/I-680 Ramp | 2
+ I- 580/I-680 Ramp | 2
+ I- 580/I-680 Ramp | 2
+ I- 580/I-680 Ramp | 2
+ I- 580/I-680 Ramp | 4
+ I- 580/I-680 Ramp | 4
+ I- 580/I-680 Ramp | 4
+ I- 580/I-680 Ramp | 4
+ I- 580/I-680 Ramp | 5
+ I- 580/I-680 Ramp | 6
+ I- 580/I-680 Ramp | 6
+ I- 580/I-680 Ramp | 6
I- 580 Ramp | 2
I- 580 Ramp | 2
I- 580 Ramp | 2
***************
*** 665,684 ****
I- 580 Ramp | 8
I- 580 Ramp | 8
I- 580 Ramp | 8
- I- 580/I-680 Ramp | 2
- I- 580/I-680 Ramp | 2
- I- 580/I-680 Ramp | 2
- I- 580/I-680 Ramp | 2
- I- 580/I-680 Ramp | 2
- I- 580/I-680 Ramp | 2
- I- 580/I-680 Ramp | 4
- I- 580/I-680 Ramp | 4
- I- 580/I-680 Ramp | 4
- I- 580/I-680 Ramp | 4
- I- 580/I-680 Ramp | 5
- I- 580/I-680 Ramp | 6
- I- 580/I-680 Ramp | 6
- I- 580/I-680 Ramp | 6
I- 680 | 2
I- 680 | 2
I- 680 | 2
--- 679,684 --------------------------
******************************************************************************************************
/etc/sysconfig/i18n:
******************************************************************************************************
LANG="en_US"
******************************************************************************************************
On Tue, 20 Mar 2001, M, Eichhorn wrote:
2. Should i change the LANG="en_US" to LANG="C" and send your a new regression
test report?
Please. You will need to stop postmaster wipe the old database installation,
make the locale variable change, re-initdb, and start postmaster.
You seem to not have seen the same temp test failure I am seeing. Interesting.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
Dear Reinhard
I have unset LANG (blank), wiped the old database, and start postmaster
(init.d).
The result of the regression test looks pretty fine, no failure.
Thank you very much for your support.
Regards Martin
Reinhard Max wrote:
Show quoted text
On Mon, 19 Mar 2001 pgsql-bugs@postgresql.org wrote:
Installing Postgress on a Red Hat 7.0 Server, some regression test
failed (see below). How can i fix this failed queries?I had similar results here at SuSE. They came from a locale bug in
glibc-2.2 . As a workaround, try to unset LANG or set it to POSIX
before starting the postmaster. AFAIK glibc-2.2.2 will fix this bug.cu
Reinhard
Dear Lamar and Tom
I have unset LANG (blank), wiped the old database, and start postmaster
(init.d). The result of the regression test looks pretty fine, no failure.
What's about other application when LANG=blank?
Thank you very much for your support.
Regards Martin
Lamar Owen wrote:
Show quoted text
On Tue, 20 Mar 2001, M, Eichhorn wrote:
2. Should i change the LANG="en_US" to LANG="C" and send your a new regression
test report?
Please. You will need to stop postmaster wipe the old database installation,
make the locale variable change, re-initdb, and start postmaster.You seem to not have seen the same temp test failure I am seeing. Interesting.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11