Non-locale 7.1beta4 binaries on RedHat 6.2 test results.

Started by Lamar Owenalmost 25 years ago3 messages
#1Lamar Owen
lamar.owen@wgcr.org
1 attachment(s)

Ok, after Tatsuo and Peter have both said that building without locale
support should not use the locale support in the OS, and remembering my
6.5.3 experience of a year back, I decided to test it out completely.
And I am wrong with respect to 7.1beta4.

For 7.1beta4 disabling locale will indeed work properly, at least on
RedHat 6.2.

Testing methodology:
1.) Blow out entire PGDATA tree;
2.) Initdb with locale-enabled backend;
3.) Run regression with locale-enable binaries (locale=en_US);
4.) Rebuild without --enable-locale;
5.) Blow out entire PGDATA tree;
6.) Initdb with non-locale backend;
7.) Run regression with non-locale binaries.

Results:
For --enable-locale RPM's, pg_regress --schedule=parallel_schedule
produces:
parallel group (13 tests): boolean char name varchar int4 int2 oid
float4 float
8 text bit int8 numeric
boolean ... ok
char ... ok
name ... ok
varchar ... ok
text ... ok
int2 ... ok
int4 ... ok
int8 ... FAILED
oid ... ok
float4 ... ok
float8 ... ok
bit ... ok
numeric ... FAILED
test strings ... ok
test numerology ... ok
parallel group (18 tests): point lseg box path polygon circle comments
reltime
date abstime interval time inet type_sanity tinterval timestamp oidjoins
opr_san
ity
point ... ok
lseg ... ok
box ... ok
path ... ok
polygon ... ok
circle ... ok
date ... ok
time ... ok
timestamp ... ok
interval ... ok
abstime ... ok
reltime ... ok
tinterval ... ok
inet ... ok
comments ... ok
oidjoins ... ok
type_sanity ... ok
opr_sanity ... ok
test geometry ... ok
test horology ... ok
test create_function_1 ... ok
test create_type ... ok
test create_table ... ok
test create_function_2 ... ok
test copy ... ok
parallel group (7 tests): create_aggregate create_operator triggers
inherit con
straints create_misc create_index
constraints ... ok
triggers ... ok
create_misc ... ok
create_aggregate ... ok
create_operator ... ok
create_index ... ok
inherit ... ok
test create_view ... ok
test sanity_check ... ok
test errors ... ok
test select ... ok
parallel group (16 tests): select_into select_distinct_on
select_distinct selec
t_having select_implicit subselect transactions union case random arrays
aggrega
tes join portals hash_index btree_index
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 ... failed (ignored)
portals ... ok
arrays ... ok
btree_index ... ok
hash_index ... ok
test misc ... ok
parallel group (5 tests): portals_p2 alter_table rules foreign_key
select_views
select_views ... FAILED
alter_table ... ok
portals_p2 ... ok
rules ... ok
foreign_key ... ok
parallel group (3 tests): limit temp plpgsql
limit ... ok
plpgsql ... ok
temp ... ok
----

With locale disabled:
All 76 tests passed.

So, there's the data. This is different behavior from the 6.5.3
non-locale set I produced a year ago. Is there interest in a non-locale
RPM distribution, or? The locale enabled regression results fail due to
currency format and collation errors. Diffs attached. I'm not sure I
understand the select_views failure, either. Locale used was en_US.

Comments?
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Attachments:

locale-run.diffsapplication/x-unknown-content-type-diffs_auto_file; name=locale-run.diffsDownload
*** ./expected/int8.out	Sun Jan 28 21:53:58 2001
--- ./results/int8.out	Sat Feb 17 09:32:14 2001
***************
*** 236,246 ****
  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;
--- 236,246 ----
  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 15:17:42 2000
--- ./results/numeric.out	Sat Feb 17 09:32:29 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	Tue Sep 12 17:07:17 2000
--- ./results/select_implicit.out	Sat Feb 17 09:33:01 2001
***************
*** 23,32 ****
  ----------+-------
   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
--- 23,32 ----
  ----------+-------
   AAAA     |     2
   BBBB     |     2
   bbbb     |     1
+  CCCC     |     2
   cccc     |     2
+  XXXX     |     1
  (6 rows)
  
  --   w/o existing GROUP BY target using a relation name in GROUP BY clause
***************
*** 35,44 ****
  -------
       2
       2
-      2
-      1
       1
       2
  (6 rows)
  
  --   w/o existing GROUP BY target and w/o existing a different ORDER BY target
--- 35,44 ----
  -------
       2
       2
       1
       2
+      2
+      1
  (6 rows)
  
  --   w/o existing GROUP BY target and w/o existing a different ORDER BY target
***************
*** 105,114 ****
  ----------+-------
   AAAA     |     2
   BBBB     |     2
-  CCCC     |     2
-  XXXX     |     1
   bbbb     |     1
   cccc     |     2
  (6 rows)
  
  --   group using reference number out of range
--- 105,114 ----
  ----------+-------
   AAAA     |     2
   BBBB     |     2
   bbbb     |     1
+  CCCC     |     2
   cccc     |     2
+  XXXX     |     1
  (6 rows)
  
  --   group using reference number out of range

======================================================================

*** ./expected/select_having.out	Thu Jan  6 01:40:54 2000
--- ./results/select_having.out	Sat Feb 17 09:33:01 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/random.out	Thu Jan  6 01:40:54 2000
--- ./results/random.out	Sat Feb 17 09:33:02 2001
***************
*** 31,35 ****
    WHERE random NOT BETWEEN 80 AND 120;
   random 
  --------
! (0 rows)
  
--- 31,36 ----
    WHERE random NOT BETWEEN 80 AND 120;
   random 
  --------
!     123
! (1 row)
  

======================================================================

*** ./expected/select_views.out	Sat Jan  8 22:48:37 2000
--- ./results/select_views.out	Sat Feb 17 09:33:13 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 ----

======================================================================

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Lamar Owen (#1)
Re: Non-locale 7.1beta4 binaries on RedHat 6.2 test results.

Lamar Owen <lamar.owen@wgcr.org> writes:

The locale enabled regression results fail due to
currency format and collation errors. Diffs attached. I'm not sure I
understand the select_views failure, either. Locale used was en_US.

The select_views delta looks like a sort-order issue as well; nothing
to worry about.

These deltas would go away if you allowed pg_regress to build a temp
installation in which it could force the locale to C. Of course,
that doesn't presently work without a built source tree to install
from. I wonder if it is worth adding a third operating mode to
pg_regress that would build a temp PGDATA directory but use the
already-installed bin/lib/share directories ...

regards, tom lane

#3Lamar Owen
lamar.owen@wgcr.org
In reply to: Lamar Owen (#1)
Re: Non-locale 7.1beta4 binaries on RedHat 6.2 test results.

Tom Lane wrote:

Lamar Owen <lamar.owen@wgcr.org> writes:

The locale enabled regression results fail due to
currency format and collation errors. Diffs attached. I'm not sure I
understand the select_views failure, either. Locale used was en_US.

The select_views delta looks like a sort-order issue as well; nothing
to worry about.

Good. I didn't see any difference -- but maybe that's because I went
cross-eyed.... :-)

These deltas would go away if you allowed pg_regress to build a temp
installation in which it could force the locale to C. Of course,
that doesn't presently work without a built source tree to install
from. I wonder if it is worth adding a third operating mode to

Possibly. If pg_regress uses a different port for postmaster, AND a
different PGDATA, you could run regression on a sandbox while a
production system was running, FWIW. Since that's more of an RPM issue
than a core issue, I can do that third mode work, as I would be the
direct benefactor (unless someone else does it first, of course).

Both the locale and non-locale installation were from RPM, BTW, as I
wanted the least number of variables possible.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11