Re: BUG #6760: make check fails on strings SQL T581 regex test

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 used the following configure command:

LDFLAGS="-L/usr/local/lib" LIBS="-lmass" CC=xlc_r CFLAGS="-qtune=auto -qarch=auto -qcache=auto -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 (which 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 clean check", to find that I no longer had the regex error.

As this behaviour pointed to a compiler issue, I updated the compiler to xlcV12.1.0.0 and reran the "make clean check" and the result was no regex error 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 script 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 reads:

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

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

============== shutting down postmaster ==============

=======================
All 126 tests passed.
=======================

Jez Wain

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

> jez(dot)wain(at)bull(dot)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