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.w...@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
