Обсуждение: 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)

CC="xlC_r -q64" \<br />CXX="xlC_r -q64" \<br />AR="ar -X64" \<br />OBJECT_MODE=64 \<br
/>PATH=/usr/bin:/usr/vacpp/bin<br/>./configure<br />make<br /><br />Make builds fine, but pg_regress: initdb fails.
src/test/regress/logreads:<br /><br />Running in noclean mode.  Mistakes will not be cleaned up.<br />The files
belongingto this database system will be owned by user "cmihai".<br />This user must also own the server process.<br
/><br/>The database cluster will be initialized with locale C.<br /> The default database encoding has accordingly been
setto SQL_ASCII.<br />The default text search configuration will be set to "english".<br /><br />creating directory
/home/cmihai/build/postgresql-8.3.6/src/test/regress/./tmp_check/data... ok<br /> creating subdirectories ... ok<br
/>selectingdefault max_connections ... 100<br />selecting default shared_buffers/max_fsm_pages ... 32MB/204800<br
/>creatingconfiguration files ... ok<br />creating template1 database in
/home/cmihai/build/postgresql-8.3.6/src/test/regress/./tmp_check/data/base/1... ok<br /> initializing pg_authid ...
ok<br/>initializing dependencies ... ok<br />creating system views ... WARNING:  could not dump unrecognized node type:
650<br/>WARNING:  could not dump unrecognized node type: 650<br />WARNING:  could not dump unrecognized node type:
650<br/> WARNING:  could not dump unrecognized node type: 650<br />WARNING:  could not dump unrecognized node type:
650<br/>WARNING:  could not dump unrecognized node type: 650<br />WARNING:  could not dump unrecognized node type:
650<br/> WARNING:  could not dump unrecognized node type: 650<br />WARNING:  could not dump unrecognized node type:
650<br/>WARNING:  could not dump unrecognized node type: 650<br />WARNING:  could not dump unrecognized node type:
650<br/> FATAL:  badly formatted node string "} {} {} {} {} {} {} {} {} {} {})"...<br />STATEMENT:  /*<br />         *
PostgreSQLSystem Views<br />         *<br />         * Copyright (c) 1996-2008, PostgreSQL Global Development Group<br
/>         *<br />         * $PostgreSQL: pgsql/src/backend/catalog/system_views.sql,v 1.48 2008/01/01 19:45:48 momjian
Exp$<br />         */<br /><br />        CREATE VIEW pg_roles AS<br />            SELECT<br /><br /><br />[[ more code
here]]<br />         LANGUAGE SQL STRICT STABLE;<br /><br />        COMMENT ON FUNCTION ts_debug(text) IS<br
/>           'debug function for current text search configuration';<br /><br />child process exited with exit code
1<br/>initdb: data directory "/home/cmihai/build/postgresql-8.3.6/src/test/regress/./tmp_check/data" not removed at
user'srequest<br /><br clear="all" /><br /><br />make install is successful, but of course, initdb will fail in a
similarmanner. (WARNING:  could not dump unrecognized node type: 650<br />FATAL:  badly formatted node string "} {} {}
{}{} {} {} {} {} {} {})"... after initializing dependencies ... ok).<br /><br />initdb: 64-bit XCOFF executable or
objectmodule not stripped<br /><br />All commands seem to be work in so far as they don't have missing modules (ldd)
andrun. Not much else I can test without a initdb though.<br /><br /> I have found my issue to be similar to <a
href="http://archives.postgresql.org/pgsql-ports/2005-06/msg00002.php">http://archives.postgresql.org/pgsql-ports/2005-06/msg00002.php</a>
(unresolved).<br/><br />Any suggestions / additional tests I can run to pinpoint the problem?<br /><br />If I use IBM
Debuggerof AIX, I get right before the crash:<br /><br />creating system views ...<br />exec() -> sh<br />exec()
->postgres<br />Execution terminated.<br /><br />So it happens somewhere in postgres code.<br /><br /> -- <br
/>CrivetiMihai<br /><a href="http://unixsadm.blogspot.com" target="_blank">http://unixsadm.blogspot.com</a><br /><br /> 

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
>

I'm working on building the dependencies to run a build farm script on it, may get better debugging results.

In the meantime, I haveanother build with:
./configure --enable-cassert --enable-debug --with-includes=/opt/freeware/include --with-libraries=/opt/freeware/lib --enable-thread-safety && gmake
gmake
sudo gmake install

Based on flags I've seen on the build farm configs. It fails in an identical manner. From what I've seen, initdb execs quite a few things, but fails at the exec () postgresql:

Here's /usr/local/pgsql/bin/initdb -d -D /usr/local/pgsql/data


[[ .. same as before, but with more debug..]]
DEBUG:  name: unnamed; blockState:       DEFAULT; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children:
DEBUG:  start transaction
DEBUG:  CommitTransaction
DEBUG:  name: unnamed; blockState:       STARTED; state: INPROGR, xid/subid/cid: 1/1/1, nestlvl: 1, children:
DEBUG:  commit transaction
DEBUG:  StartTransaction
DEBUG:  name: unnamed; blockState:       DEFAULT; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children:
DEBUG:  start transaction
DEBUG:  CommitTransaction
DEBUG:  name: unnamed; blockState:       STARTED; state: INPROGR, xid/subid/cid: 0/1/35, nestlvl: 1, children:
DEBUG:  commit transaction
DEBUG:  proc_exit(0)
DEBUG:  shmem_exit(0)
DEBUG:  exit(0)
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





--
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

The system and compiler are patched with the latest fix packs from IBM, and the compiler version is the latest
available.<br /><br />The compiler is functional (eg: I was able to compile successfuly 64 bit versions other software
suchas Apache 2.2.11, emacs 22.3, vim 7.2, openssl-0.9.8j and so on, all with similar flags).<br /><br />So if this is
acompiler bug, it certainly isn't an obvious one. I'll dig deeper to see how I can convince configure to use
-qnooptimize.<br/><br />The first build was using default options for xlC_r (the default for all IBM compilers is
-qnooptimize)../configure seems to override this:<br /><br />When I've used the build farm scripts, configure gives
xlC_rthese flags:<br /><br />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<br /> 1506-396 (W) Option -qlonglong
isincompatible with option -qlanglvl=extc99 and is ignored.<br />ld: 0711-317 ERROR: Undefined symbol: .setproctitle<br
/>ld:0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.<br /> configure:7123: $? = 8<br /><br
/>I'lltry a 32 bit build too.<br /><br /><div class="gmail_quote">On Mon, Feb 9, 2009 at 8:58 AM, Tom Lane <span
dir="ltr"><<ahref="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>></span> wrote:<br /><blockquote
class="gmail_quote"style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left:
1ex;"><divclass="Ih2E3d">Mihai Criveti <<a href="mailto:cmihai@boreas.ro">cmihai@boreas.ro</a>> writes:<br />
>creating system views ... WARNING:  could not dump unrecognized node type:<br /> > 650<br /> > WARNING:
 couldnot dump unrecognized node type: 650<br /> > WARNING:  could not dump unrecognized node type: 650<br /> >
WARNING: could not dump unrecognized node type: 650<br /> > WARNING:  could not dump unrecognized node type: 650<br
/>> WARNING:  could not dump unrecognized node type: 650<br /> > WARNING:  could not dump unrecognized node type:
650<br/> > WARNING:  could not dump unrecognized node type: 650<br /> > WARNING:  could not dump unrecognized
nodetype: 650<br /> > WARNING:  could not dump unrecognized node type: 650<br /> > WARNING:  could not dump
unrecognizednode type: 650<br /> > FATAL:  badly formatted node string "} {} {} {} {} {} {} {} {} {} {})"...<br
/><br/></div>My, that's interesting.  A look at nodes.h shows that 650 == T_Value,<br /> which simply should not ever
occuras a live node type.  Unless my grep<br /> is missing something, T_Value itself is never directly referenced<br />
anywherein the 8.3 source code.  There are five occurrences of<br /> makeNode(Value) but each of them immediately
overwritesthe node type<br /> field with another type code such as T_Integer or T_String.<br /><br /> Not to put too
finea point on it, but I'm thinking "compiler bug".<br /> You might try a build with the optimization level backed off
tosee<br /> if the problem goes away.<br /><br />                        regards, tom lane<br /></blockquote></div><br
/><brclear="all" /><br />-- <br />Criveti Mihai<br /><a
href="http://unixsadm.blogspot.com">http://unixsadm.blogspot.com</a><br/><br /> 

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

OK, I've managed to compile a 32 bit PostgreSQL successfully and it runs. I'm not yet sure if the issues are due to
usingthe C++ compiler to compile C code, optimization flags or 64 bit builts, but I'll rebuilt it a few times to
pinpointthe real issue.<br /><br />Either way, I think it was my mistake to use xlC_r instead of xlc_r. Thanks a lot
forthe support.<br />If I get these issues sorted out, I'll see if I can add the machine to the buildfarm.<br /><br
/>I'verecompiled it with clean environment variables (no CC defined, etc), using xlc (/usr/vac/bin/xlc_r), the C
compilerinstead of using xlC_r (the C++ compiler). No -q64 (64 bit build) and using:<br /><br />CFLAGS='-qnooptimize'
./configure--enable-cassert --enable-debug --with-includes=/opt/freeware/include --with-libraries=/opt/freeware/lib
--enable-thread-safety<br/><br />I see gmake using:<br />xlc -qnooptimize -qnoansialias -g -I../../../src/include
-I/opt/freeware/include -c -o pg_enum.o pg_enum.c<br /><br />Now initdb runs fine.<br /><br />phobos$
/usr/local/pgsql/bin/initdb-D /usr/local/pgsql/data<br />The files belonging to this database system will be owned by
user"postgres".<br />This user must also own the server process.<br /><br />The database cluster will be initialized
withlocale en_US.<br />The default database encoding has accordingly been set to LATIN1.<br />The default text search
configurationwill be set to "english".<br /><br />fixing permissions on existing directory /usr/local/pgsql/data ...
ok<br/> creating subdirectories ... ok<br />selecting default max_connections ... 100<br />selecting default
shared_buffers/max_fsm_pages... 32MB/204800<br />creating configuration files ... ok<br />creating template1 database
in/usr/local/pgsql/data/base/1 ... ok<br /> initializing pg_authid ... ok<br />initializing dependencies ... ok<br
/>creatingsystem views ... ok<br />loading system objects' descriptions ... ok<br />creating conversions ... ok<br
/>creatingdictionaries ... ok<br />setting privileges on built-in objects ... ok<br /> creating information schema ...
ok<br/>vacuuming database template1 ... ok<br />copying template1 to template0 ... ok<br />copying template1 to
postgres... ok<br /><br />WARNING: enabling "trust" authentication for local connections<br /> You can change this by
editingpg_hba.conf or using the -A option the<br />next time you run initdb.<br /><br />Success. You can now start the
databaseserver using:<br /><br />    /usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data<br /> or<br />   
/usr/local/pgsql/bin/pg_ctl-D /usr/local/pgsql/data -l logfile start<br /><br /><br /><div class="gmail_quote">On Mon,
Feb9, 2009 at 9:40 AM, Tom Lane <span dir="ltr"><<a href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>></span>
wrote:<br/><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex;
padding-left:1ex;"><div class="Ih2E3d">Mihai Criveti <<a href="mailto:cmihai@boreas.ro">cmihai@boreas.ro</a>>
writes:<br/></div><div class="Ih2E3d">> So if this is a compiler bug, it certainly isn't an obvious one. I'll dig<br
/>> deeper to see how I can convince configure to use -qnooptimize.<br /><br /></div>Set CFLAGS in its environment.
 Thedefault is set in src/template/aix<br />      CFLAGS="-O2 -qmaxmem=16384 -qsrcmsg -qlonglong"<br /><div
class="Ih2E3d"><br/> > When I've used the build farm scripts, configure gives xlC_r these flags:<br /> >
configure:7117:xlC_r -q64 -o conftest -O2 -qmaxmem=16384 -qsrcmsg<br /> > -qlonglong -g
 -I/opt/freeware/include/libxml2  -L/opt/freeware/lib<br /> > conftest.c -lm  >&5<br /><br /></div>Dunno
wherethe -q64 came from ...<br /><div class="Ih2E3d"><br /> > 1506-396 (W) Option -qlonglong is incompatible with
option-qlanglvl=extc99<br /> > and is ignored.<br /><br /></div>Seems like these switches might need a revisit for
latestAIX.<br /><br />                        regards, tom lane<br /></blockquote></div><br /><br clear="all" /><br
/>--<br />Criveti Mihai<br /><a href="http://unixsadm.blogspot.com">http://unixsadm.blogspot.com</a><br /><br /> 

> > 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,
andended up with some horrible compiler optimization or something that killed it.<br /><br /> Are there any other tests
Ican run now that PostgreSQL is installed?<br /><br />Seems to work fine for basic stuff anyway.<br />phobos%
/usr/local/pgsql/bin/pg_ctl-D /usr/local/pgsql/data -l logfile start<br />server starting<br /> phobos%
/usr/local/pgsql/bin/psql-U postgres<br />Welcome to psql 8.3.6, the PostgreSQL interactive terminal.<br /><br />Type: 
\copyrightfor distribution terms<br />       \h for help with SQL commands<br />       \? for help with psql
commands<br/>        \g or terminate with semicolon to execute query<br />       \q to quit<br /><br />postgres=#
CREATEROLE testuser LOGIN PASSWORD 'test123';<br />CREATE ROLE<br />postgres=# CREATE DATABASE testdb;<br />CREATE
DATABASE<br/> postgres=# CREATE TABLE test (ID serial PRIMARY KEY, name varchar(25) NOT NULL UNIQUE);<br />NOTICE: 
CREATETABLE will create implicit sequence "test_id_seq" for serial column "<a href="http://test.id">test.id</a>"<br />
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "test_pkey" for table "test"<br />NOTICE:  CREATE TABLE /
UNIQUEwill create implicit index "test_name_key" for table "test"<br /> CREATE TABLE<br />postgres=# INSERT INTO test
VALUES(default, 'quux');<br />INSERT 0 1<br />postgres=# SELECT * FROM test;<br /> id | name<br />----+------<br />  1
|quux<br />(1 row)<br />\q<br /><br /><br /><div class="gmail_quote"> On Mon, Feb 9, 2009 at 11:40 AM, Zeugswetter
AndreasOSB sIT <span dir="ltr"><<a
href="mailto:Andreas.Zeugswetter@s-itsolutions.at">Andreas.Zeugswetter@s-itsolutions.at</a>></span>wrote:<br
/><blockquoteclass="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex;
padding-left:1ex;"><div class="Ih2E3d"><br /> > > So if this is a compiler bug, it certainly isn't an obvious
one.I'll dig<br /> > > deeper to see how I can convince configure to use -qnooptimize.<br /> ><br /> > Set
CFLAGSin its environment.  The default is set in src/template/aix<br /> >       CFLAGS="-O2 -qmaxmem=16384 -qsrcmsg
-qlonglong"<br/> ><br /> > > When I've used the build farm scripts, configure gives xlC_r these flags:<br />
>> configure:7117: xlC_r -q64 -o conftest -O2 -qmaxmem=16384 -qsrcmsg<br /> > > -qlonglong -g
 -I/opt/freeware/include/libxml2  -L/opt/freeware/lib<br /> > > conftest.c -lm  >&5<br /><br /></div>Um,
whyare you using the C++ frontend ? Have you tried xlc_r or cc_r instead ?<br /><br /> Using xlC_r or xlc_r, implicitly
sets-qansialias. IIRC we had some issues with<br /> aliasing on other platforms too ? Would that switch be wrong ?<br
/>Doc sais: "Use type-based aliasing during optimization."<br /><div class="Ih2E3d"><br /> > Dunno where the -q64
camefrom ...<br /><br /></div>Probably together with the choice of compiler command ?<br /><font color="#888888"><br />
Andreas</font></blockquote></div><br/><br clear="all" /><br />-- <br />Criveti Mihai<br /><a
href="http://unixsadm.blogspot.com">http://unixsadm.blogspot.com</a><br/><br /> 

> 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





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

All regression tests work. Everything seems to be in order :-)

Followup with regression tests (rand the installchecks as postgres user):

$ gmake check
[..]
=======================
 All 114 tests passed.
=======================

[after setting up the database and all:]

$ gmake installcheck
...
test xml                  ... ok
test stats                ... ok
test tablespace           ... ok
=======================
 All 114 tests passed.
=======================

$ gmake installcheck-parallel

=======================
 All 114 tests passed.
=======================

gmake[2]: Leaving directory `/home/cmihai/build/postgresql-8.3.6/src/test/regress'
gmake[1]: Leaving directory `/home/cmihai/build/postgresql-8.3.6/src/test'






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

Mihai Criveti <cmihai@boreas.ro> writes:
> 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"

Hmm.  I think -qnoansialias corresponds to gcc's -fno-strict-aliasing,
which we *know* is necessary to build a working Postgres on recent gcc
versions.  I have not checked the exact symptoms of -fstrict-aliasing
recently, but what you're reporting is definitely consistent with the
idea that the compiler is improperly reordering some assignments, which
is basically what the aliasing business is about.  So that switch seems
like the critical issue here.

I see that configure knows about that switch, but it only tries to use
it if CC = xlc:

elif test x"${CC}" = x"xlc"; then # AIX xlc has to have strict aliasing turned off too
PGAC_PROG_CC_CFLAGS_OPT([-qnoansialias])
fi

So it seems we have a couple of problems here.  Using xlc_r or xlC_r
or adding -q64 to CC (rather than CFLAGS which is where it really
belongs) will confuse this check.  It also seems a bit schizophrenic
to have this bit of knowledge wired into configure itself while there
are some other AIX-specific switches in src/template/aix.

Would it be reasonable to change the test quoted above to

elif test "$PORTNAME" = "aix"; then ...

that is try -qnoansialias anytime the compiler isn't gcc and the
platform is aix?  Is xlc used on any platform other than aix?

Also, has anyone got a clue what the switches selected in
src/template/aix actually do, and whether they still make sense
for modern AIX versions?
        regards, tom lane

On 9 Feb 2009, at 16:04, Tom Lane wrote:
>
> Hmm.  I think -qnoansialias corresponds to gcc's -fno-strict-aliasing,
> which we *know* is necessary to build a working Postgres on recent gcc
> versions.  I have not checked the exact symptoms of -fstrict-aliasing
> recently, but what you're reporting is definitely consistent with the
> idea that the compiler is improperly reordering some assignments,  
> which
> is basically what the aliasing business is about.  So that switch  
> seems
> like the critical issue here.

Just for the record Tom, I am building postgresql on my test box with  
vectoring (-ftree-vectorize) and -O3, which pretty much turns the  
strict-aliasing flag off.
it compiles, passes default tests, passes my tests, and works  
beautifully. Vectoring is pretty much only used in numeric code.

That's on 32bit machine, mac os x.

Tom Lane wrote:
> So it seems we have a couple of problems here.  Using xlc_r or xlC_r
> or adding -q64 to CC (rather than CFLAGS which is where it really
> belongs) will confuse this check.

Correction: Flags that determine the architecture usually belong in CC, 
not in CFLAGS.

Test case for when a flag belongs into CC instead of CFLAGS:

To compile a file, you use $(CC) $(CPPFLAGS) $(CFLAGS).

To preprocess a file, you use $(CPP) $(CPPFLAGS), where CPP is usually 
$(CC) -E.

If you have a compiler flag that applies for preprocessing, you must put 
it into CC.

Another class of flags that is typically put into CC are those selecting 
the C standards mode.

> Would it be reasonable to change the test quoted above to
> 
> elif test "$PORTNAME" = "aix"; then ...
> 
> that is try -qnoansialias anytime the compiler isn't gcc and the
> platform is aix?  Is xlc used on any platform other than aix?

That would probably make sense.  I think we just never supported xlc_r, 
and the threading code rejects a separate thread-safe compiler.

> Also, has anyone got a clue what the switches selected in
> src/template/aix actually do, and whether they still make sense
> for modern AIX versions?

-qmaxmem=16384 is the memory for optimizations (in bytes).

-qsrcmsg prints the affected code line in a compiler error (instead of 
just file name and line number).

-qlonglong is clear.

Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane wrote:
>> Would it be reasonable to change the test quoted above to
>> 
>> elif test "$PORTNAME" = "aix"; then ...
>> 
>> that is try -qnoansialias anytime the compiler isn't gcc and the
>> platform is aix?  Is xlc used on any platform other than aix?

> That would probably make sense.  I think we just never supported xlc_r, 
> and the threading code rejects a separate thread-safe compiler.

Done in CVS HEAD.
        regards, tom lane