Re: 64 bit PostgreSQL 8.3.6 build on AIX 5300-09-02-0849 with IBM XL C/C++ 10.1.0.1 - initdb fails (could not dump unrecognized node type: 650)

Please try configuring with --enable-debug --enable-cassert

Then if you don't get any more useful information you might need to try initdb -d

cheers

andrew

Mihai Criveti wrote:

CC="xlC_r -q64" \
CXX="xlC_r -q64" \
AR="ar -X64" \
OBJECT_MODE=64 \
PATH=/usr/bin:/usr/vacpp/bin
./configure
make

Make builds fine, but pg_regress: initdb fails. src/test/regress/log reads:

Running in noclean mode.  Mistakes will not be cleaned up.
The files belonging to this database system will be owned by user "cmihai".
This user must also own the server process.

The database cluster will be initialized with locale C.
The default database encoding has accordingly been set to SQL_ASCII.
The default text search configuration will be set to "english".

creating directory /home/cmihai/build/postgresql-8.3.6/src/test/regress/./tmp_check/data ... ok
creating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers/max_fsm_pages ... 32MB/204800
creating configuration files ... ok
creating template1 database in /home/cmihai/build/postgresql-8.3.6/src/test/regress/./tmp_check/data/base/1 ... ok
initializing pg_authid ... ok
initializing dependencies ... ok
creating system views ... WARNING:  could not dump unrecognized node type: 650
WARNING:  could not dump unrecognized node type: 650
WARNING:  could not dump unrecognized node type: 650
WARNING:  could not dump unrecognized node type: 650
WARNING:  could not dump unrecognized node type: 650
WARNING:  could not dump unrecognized node type: 650
WARNING:  could not dump unrecognized node type: 650
WARNING:  could not dump unrecognized node type: 650
WARNING:  could not dump unrecognized node type: 650
WARNING:  could not dump unrecognized node type: 650
WARNING:  could not dump unrecognized node type: 650
FATAL:  badly formatted node string "} {} {} {} {} {} {} {} {} {} {})"...
STATEMENT:  /*
        * PostgreSQL System Views
        *
        * Copyright (c) 1996-2008, PostgreSQL Global Development Group
        *
        * $PostgreSQL: pgsql/src/backend/catalog/system_views.sql,v 1.48 2008/01/01 19:45:48 momjian Exp $
        */

       CREATE VIEW pg_roles AS
           SELECT


[[ more code here ]]
       LANGUAGE SQL STRICT STABLE;

       COMMENT ON FUNCTION ts_debug(text) IS
           'debug function for current text search configuration';

child process exited with exit code 1
initdb: data directory "/home/cmihai/build/postgresql-8.3.6/src/test/regress/./tmp_check/data" not removed at user's request



make install is successful, but of course, initdb will fail in a similar manner. (WARNING:  could not dump unrecognized node type: 650
FATAL:  badly formatted node string "} {} {} {} {} {} {} {} {} {} {})"... after initializing dependencies ... ok).

initdb: 64-bit XCOFF executable or object module not stripped

All commands seem to be work in so far as they don't have missing modules (ldd) and run. Not much else I can test without a initdb though.

I have found my issue to be similar to http://archives.postgresql.org/pgsql-ports/2005-06/msg00002.php (unresolved).

Any suggestions / additional tests I can run to pinpoint the problem?

If I use IBM Debugger of AIX, I get right before the crash:

creating system views ...
exec() -> sh
exec() -> postgres
Execution terminated.

So it happens somewhere in postgres code.

--
Criveti Mihai
http://unixsadm.blogspot.com

Mihai Criveti <cmihai@boreas.ro> writes:
> creating system views ... WARNING:  could not dump unrecognized node type:
> 650
> WARNING:  could not dump unrecognized node type: 650
> WARNING:  could not dump unrecognized node type: 650
> WARNING:  could not dump unrecognized node type: 650
> WARNING:  could not dump unrecognized node type: 650
> WARNING:  could not dump unrecognized node type: 650
> WARNING:  could not dump unrecognized node type: 650
> WARNING:  could not dump unrecognized node type: 650
> WARNING:  could not dump unrecognized node type: 650
> WARNING:  could not dump unrecognized node type: 650
> WARNING:  could not dump unrecognized node type: 650
> FATAL:  badly formatted node string "} {} {} {} {} {} {} {} {} {} {})"...

My, that's interesting.  A look at nodes.h shows that 650 == T_Value,
which simply should not ever occur as a live node type.  Unless my grep
is missing something, T_Value itself is never directly referenced
anywhere in the 8.3 source code.  There are five occurrences of
makeNode(Value) but each of them immediately overwrites the node type
field with another type code such as T_Integer or T_String.

Not to put too fine a point on it, but I'm thinking "compiler bug".
You might try a build with the optimization level backed off to see
if the problem goes away.

                       regards, tom lane

Mihai Criveti <cmihai@boreas.ro> writes:

> So if this is a compiler bug, it certainly isn't an obvious one. I'll dig
> deeper to see how I can convince configure to use -qnooptimize.

Set CFLAGS in its environment.  The default is set in src/template/aix
     CFLAGS="-O2 -qmaxmem=16384 -qsrcmsg -qlonglong"

> When I've used the build farm scripts, configure gives xlC_r these flags:
> configure:7117: xlC_r -q64 -o conftest -O2 -qmaxmem=16384 -qsrcmsg
> -qlonglong -g  -I/opt/freeware/include/libxml2   -L/opt/freeware/lib
> conftest.c -lm  >&5

Dunno where the -q64 came from ...

> 1506-396 (W) Option -qlonglong is incompatible with option -qlanglvl=extc99
> and is ignored.

Seems like these switches might need a revisit for latest AIX.

                       regards, tom lane

> > So if this is a compiler bug, it certainly isn't an obvious one. I'll dig
> > deeper to see how I can convince configure to use -qnooptimize.
>
> Set CFLAGS in its environment.  The default is set in src/template/aix
>       CFLAGS="-O2 -qmaxmem=16384 -qsrcmsg -qlonglong"
>
> > When I've used the build farm scripts, configure gives xlC_r these flags:
> > configure:7117: xlC_r -q64 -o conftest -O2 -qmaxmem=16384 -qsrcmsg
> > -qlonglong -g  -I/opt/freeware/include/libxml2   -L/opt/freeware/lib
> > conftest.c -lm  >&5

Um, why are you using the C++ frontend ? Have you tried xlc_r or cc_r instead ?

Using xlC_r or xlc_r, implicitly sets -qansialias. IIRC we had some issues with
aliasing on other platforms too ? Would that switch be wrong ?
Doc sais: "Use type-based aliasing during optimization."

> Dunno where the -q64 came from ...

Probably together with the choice of compiler command ?

Andreas

> Yes, I've had CC exported as xlC_r -q64 to do 64 bit builds, and use vacpp
> C++ instead of C. Guess it didn't like that, and ended up with some horrible
> compiler optimization or something that killed it.

Have you determined whether the problem is optimization or 64bit ?

> Are there any other tests I can run now that PostgreSQL is installed?

Well, the next thing would be running the regression tests.

Since the -qnooptimize build is not optimal, an interesting build would probably be with:
CC=xlc_r -q64 -qnoansialias

Andreas

OK, I've compiled a 64 bit optimized version, and it works great! No issues what so ever in configure, make or install. Thanks a lot for all the support :-).

PostgreSQL rocks!

What I've used to build it:

CC="xlc_r -q64 -qnoansialias"

AR="ar -X64"
OBJECT_MODE=64

./configure --enable-cassert --enable-debug --with-includes=/opt/freeware/include --with-libraries=/opt/freeware/lib --enable-thread-safety && gmake
sudo gmake install

/usr/local/pgsql/bin/postgres: 64-bit XCOFF executable or object module not stripped
/usr/local/pgsql/bin/initdb: 64-bit XCOFF executable or object module not stripped
(and so on)

/usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
The files belonging to this database system will be owned by user "postgres".

This user must also own the server process.

The database cluster will be initialized with locale en_US.
The default database encoding has accordingly been set to LATIN1.

The default text search configuration will be set to "english".

fixing permissions on existing directory /usr/local/pgsql/data ... ok

creating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers/max_fsm_pages ... 32MB/204800
creating configuration files ... ok

creating template1 database in /usr/local/pgsql/data/base/1 ... ok

initializing pg_authid ... ok
initializing dependencies ... ok

creating system views ... ok
loading system objects' descriptions ... ok
creating conversions ... ok
creating dictionaries ... ok
setting privileges on built-in objects ... ok
creating information schema ... ok
vacuuming database template1 ... ok
copying template1 to template0 ... ok
copying template1 to postgres ... ok

WARNING: enabling "trust" authentication for local connections
You can change this by editing pg_hba.conf or using the -A option the
next time you run initdb.

Success. You can now start the database server using:

    /usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data
or

    /usr/local/pgsql/bin/pg_ctl -D /usr/local/pgsql/data -l logfile start

% /usr/local/pgsql/bin/pg_ctl -D /usr/local/pgsql/data -l logfile start
server starting

On Mon, Feb 9, 2009 at 12:32 PM, Zeugswetter Andreas OSB sIT <Andreas.Zeugswetter@s-itsolutions.at> wrote:

> Yes, I've had CC exported as xlC_r -q64 to do 64 bit builds, and use vacpp
> C++ instead of C. Guess it didn't like that, and ended up with some horrible
> compiler optimization or something that killed it.

Have you determined whether the problem is optimization or 64bit ?

> Are there any other tests I can run now that PostgreSQL is installed?

Well, the next thing would be running the regression tests.

Since the -qnooptimize build is not optimal, an interesting build would probably be with:
CC=xlc_r -q64 -qnoansialias

Andreas

--
Criveti Mihai
http://unixsadm.blogspot.com