Обсуждение: BUG #6760: make check fails on strings SQL T581 regex test

The following bug has been logged on the website:

Bug reference:      6760
Logged by:          jez wain
Email address:      jez.wain@bull.net
PostgreSQL version: 9.1.4
Operating system:   AIX 7.1
Description:=20=20=20=20=20=20=20=20

I built 9.1.4 from sources using the following configure command:

LDFLAGS=3D"-L/usr/local/lib" LIBS=3D"-lmass" CC=3Dxlc_r CFLAGS=3D"-qtune=3D=
auto
-qarch=3Dauto -qcache=3Dauto -O2 -I/usr/local/include" ./configure
--with-openssl --disable-nls --without-zlib

I edited the src/include/pg_config.h to comment out the #define
HAVE_WCSTOMBS_L 1 definition (see earlier bug report)

The "make" completed without error=20

Running make check  produced the following output:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D creating temporary installation =
       =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D initializing database system    =
       =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D starting postmaster             =
       =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
running on port 57336 with PID 18874514
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D creating database "regression"  =
       =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
CREATE DATABASE
ALTER DATABASE
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D running regression test queries =
       =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
test tablespace               ... ok
parallel group (17 tests):  money txid float8 float4 oid int4 int2 text
varchar name char boolean int8 uuid bit enum numeric
     boolean                  ... ok
     char                     ... ok
     name                     ... ok
     varchar                  ... ok
     text                     ... ok
     int2                     ... ok
     int4                     ... ok
     int8                     ... ok
     oid                      ... ok
     float4                   ... ok
     float8                   ... FAILED
     bit                      ... ok
     numeric                  ... ok
     txid                     ... ok
     uuid                     ... ok
     enum                     ... ok
     money                    ... ok
test strings                  ... FAILED
test numerology               ... ok

  8< -----  TRUNCATED  ----- >8=20

The float8 failure appears to be a precision problem, I guess differences
between PowerPC and Intel x86 FP implementations.

The strings failure appears to be more problematic, with an error message:

"ERROR:  invalid regular expression: parentheses () not balanced".=20=20

Here are the contents of the "diff" file:

bash-4.2# cat /tmp/postgresql-9.1.4/src/test/regress/regression.diffs
*** /tmp/postgresql-9.1.4/src/test/regress/expected/float8.out  Fri Jun  1
01:07:09 2012
--- /tmp/postgresql-9.1.4/src/test/regress/results/float8.out   Wed Jul 25
10:36:03 2012
***************
*** 347,354 ****
   three |          f1          |       exp_ln_f1=20=20=20=20=20=20=20
  -------+----------------------+-----------------------
         |               1004.3 |                1004.3
!        | 1.2345678901234e+200 | 1.23456789012338e+200
!        | 1.2345678901234e-200 | 1.23456789012339e-200
  (3 rows)
=20=20
  -- cube root
--- 347,354 ----
   three |          f1          |       exp_ln_f1=20=20=20=20=20=20=20
  -------+----------------------+-----------------------
         |               1004.3 |                1004.3
!        | 1.2345678901234e+200 | 1.23456789012337e+200
!        | 1.2345678901234e-200 |  1.2345678901234e-200
  (3 rows)
=20=20
  -- cube root

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

*** /tmp/postgresql-9.1.4/src/test/regress/expected/strings.out Fri Jun  1
01:07:09 2012
--- /tmp/postgresql-9.1.4/src/test/regress/results/strings.out  Wed Jul 25
10:36:04 2012
***************
*** 315,332 ****
=20=20
  -- T581 regular expression substring (with SQL99's bizarre regexp syntax)
  SELECT SUBSTRING('abcdefg' FROM 'a#"(b_d)#"%' FOR '#') AS "bcd";
!  bcd=20
! -----
!  bcd
! (1 row)
!=20
  -- No match should return NULL
  SELECT SUBSTRING('abcdefg' FROM '#"(b_d)#"%' FOR '#') IS NULL AS "True";
!  True=20
! ------
!  t
! (1 row)
!=20
  -- Null inputs should return NULL
  SELECT SUBSTRING('abcdefg' FROM '(b|c)' FOR NULL) IS NULL AS "True";
   True=20
--- 315,326 ----
=20=20
  -- T581 regular expression substring (with SQL99's bizarre regexp syntax)
  SELECT SUBSTRING('abcdefg' FROM 'a#"(b_d)#"%' FOR '#') AS "bcd";
! ERROR:  invalid regular expression: parentheses () not balanced
! CONTEXT:  SQL function "substring" statement 1
  -- No match should return NULL
  SELECT SUBSTRING('abcdefg' FROM '#"(b_d)#"%' FOR '#') IS NULL AS "True";
! ERROR:  invalid regular expression: parentheses () not balanced
! CONTEXT:  SQL function "substring" statement 1
  -- Null inputs should return NULL
  SELECT SUBSTRING('abcdefg' FROM '(b|c)' FOR NULL) IS NULL AS "True";
   True=20

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

bash-4.2#=20

jez.wain@bull.net writes:
> ***************
> *** 347,354 ****
>    three |          f1          |       exp_ln_f1
>   -------+----------------------+-----------------------
>          |               1004.3 |                1004.3
> !        | 1.2345678901234e+200 | 1.23456789012338e+200
> !        | 1.2345678901234e-200 | 1.23456789012339e-200
>   (3 rows)

>   -- cube root
> --- 347,354 ----
>    three |          f1          |       exp_ln_f1
>   -------+----------------------+-----------------------
>          |               1004.3 |                1004.3
> !        | 1.2345678901234e+200 | 1.23456789012337e+200
> !        | 1.2345678901234e-200 |  1.2345678901234e-200
>   (3 rows)

This doesn't seem terribly surprising as a platform-specific difference.

>   -- T581 regular expression substring (with SQL99's bizarre regexp syntax)
>   SELECT SUBSTRING('abcdefg' FROM 'a#"(b_d)#"%' FOR '#') AS "bcd";
> ! ERROR:  invalid regular expression: parentheses () not balanced
> ! CONTEXT:  SQL function "substring" statement 1

This however isn't too good.  It suggests a platform-specific issue in
the regex library, but hard to say what.  Can you dig a little deeper,
maybe get a stack trace back from the call to errfinish()?  Does
compiling with -O0 change the behavior?

            regards, tom lane

This problem has been resolved; following a couple of suggestions from Tom =
Lane, it became apparent that the cause was due to the xlc compiler.  This =
mail summarizes the steps and findings, in the hope that it might be useful=
 to someone else.

My server environment is AIXv7.1 running on POWER7, with xlcV11.1.0.0.  I u=
sed the following configure command:

LDFLAGS=3D"-L/usr/local/lib" LIBS=3D"-lmass" CC=3Dxlc_r CFLAGS=3D"-qtune=3D=
auto -qarch=3Dauto -qcache=3Dauto -O2 -I/u
sr/local/include" ./configure --with-openssl --disable-nls

After editing src/include/pg_config.h to comment out the HAVE_WCSTOMBS_L (w=
hich configure incorrectly detects on AIX) I ran make check.  This produced=
 the regex error described in the initial report.

I edited the src/Makefile.global to remove all optimization and ran "make c=
lean check", to find that I no longer had the regex error.

As this behaviour pointed to a compiler issue, I  updated the compiler to x=
lcV12.1.0.0 and reran the "make clean check" and the result was no regex er=
ror even with the O2 optimization.

As you may have noticed, I stipulated the use of IBM high-performance maths=
 library, lmass, in the configure command.  Unfortunately, the configure sc=
ript places the -lm in front of -lmass in Makefile.global, which as most of=
 the APIs in lmass are duplicates of those in lm, the lmass routines never =
get called.  Swapping the order of lm and lmass, such that the LIBS line re=
ads:

LIBS =3D -lssl -lcrypto -lz -lreadline -lcurses -lld -lmass -lm

Has not only made the maths faster, but has also removed the float8 roundin=
g error, so the end of the make check now prints:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D shutting down postmaster        =
       =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 All 126 tests passed.=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


  Jez Wain

On 25 Jul 2012, at 19:10, Tom Lane wrote:

> jez.wain@bull.net writes:
>> ***************
>> *** 347,354 ****
>>   three |          f1          |       exp_ln_f1=20=20=20=20=20=20=20
>>  -------+----------------------+-----------------------
>>         |               1004.3 |                1004.3
>> !        | 1.2345678901234e+200 | 1.23456789012338e+200
>> !        | 1.2345678901234e-200 | 1.23456789012339e-200
>>  (3 rows)
>=20
>>  -- cube root
>> --- 347,354 ----
>>   three |          f1          |       exp_ln_f1=20=20=20=20=20=20=20
>>  -------+----------------------+-----------------------
>>         |               1004.3 |                1004.3
>> !        | 1.2345678901234e+200 | 1.23456789012337e+200
>> !        | 1.2345678901234e-200 |  1.2345678901234e-200
>>  (3 rows)
>=20
> This doesn't seem terribly surprising as a platform-specific difference.
>=20
>>  -- T581 regular expression substring (with SQL99's bizarre regexp synta=
x)
>>  SELECT SUBSTRING('abcdefg' FROM 'a#"(b_d)#"%' FOR '#') AS "bcd";
>> ! ERROR:  invalid regular expression: parentheses () not balanced
>> ! CONTEXT:  SQL function "substring" statement 1
>=20
> This however isn't too good.  It suggests a platform-specific issue in
> the regex library, but hard to say what.  Can you dig a little deeper,
> maybe get a stack trace back from the call to errfinish()?  Does
> compiling with -O0 change the behavior?
>=20
>             regards, tom lane