Re: [HACKERS] 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)
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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 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)
Peter Eisentraut pete...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 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)
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 using the C++ compiler to compile C code, optimization flags or 64 bit builts, but I'll rebuilt it a few times to pinpoint the real issue. Either way, I think it was my mistake to use xlC_r instead of xlc_r. Thanks a lot for the support. If I get these issues sorted out, I'll see if I can add the machine to the buildfarm. I've recompiled it with clean environment variables (no CC defined, etc), using xlc (/usr/vac/bin/xlc_r), the C compiler instead of using xlC_r (the C++ compiler). No -q64 (64 bit build) and using: CFLAGS='-qnooptimize' ./configure --enable-cassert --enable-debug --with-includes=/opt/freeware/include --with-libraries=/opt/freeware/lib --enable-thread-safety I see gmake using: xlc -qnooptimize -qnoansialias -g -I../../../src/include -I/opt/freeware/include -c -o pg_enum.o pg_enum.c Now initdb runs fine. phobos$ /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 On Mon, Feb 9, 2009 at 9:40 AM, Tom Lane t...@sss.pgh.pa.us wrote: Mihai Criveti cmi...@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 -- Criveti Mihai http://unixsadm.blogspot.com
Re: [HACKERS] 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)
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 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)
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. Are there any other tests I can run now that PostgreSQL is installed? Seems to work fine for basic stuff anyway. phobos% /usr/local/pgsql/bin/pg_ctl -D /usr/local/pgsql/data -l logfile start server starting phobos% /usr/local/pgsql/bin/psql -U postgres Welcome to psql 8.3.6, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help with psql commands \g or terminate with semicolon to execute query \q to quit postgres=# CREATE ROLE testuser LOGIN PASSWORD 'test123'; CREATE ROLE postgres=# CREATE DATABASE testdb; CREATE DATABASE postgres=# CREATE TABLE test (ID serial PRIMARY KEY, name varchar(25) NOT NULL UNIQUE); NOTICE: CREATE TABLE will create implicit sequence test_id_seq for serial column test.id NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index test_pkey for table test NOTICE: CREATE TABLE / UNIQUE will create implicit index test_name_key for table test CREATE TABLE postgres=# INSERT INTO test VALUES (default, 'quux'); INSERT 0 1 postgres=# SELECT * FROM test; id | name +-- 1 | quux (1 row) \q On Mon, Feb 9, 2009 at 11:40 AM, Zeugswetter Andreas OSB sIT andreas.zeugswet...@s-itsolutions.at wrote: 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 -- Criveti Mihai http://unixsadm.blogspot.com
[HACKERS] RE: [HACKERS] 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)
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 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)
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.zeugswet...@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
Re: [HACKERS] 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)
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' On Mon, Feb 9, 2009 at 4:06 PM, Mihai Criveti cmi...@boreas.ro wrote: 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.zeugswet...@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 -- Criveti Mihai http://unixsadm.blogspot.com
Re: [HACKERS] 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)
Mihai Criveti cmi...@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} = xxlc; 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 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)
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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] 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 \
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/msg2.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
Re: [HACKERS] 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/msg2.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 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)
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
On Mon, Feb 9, 2009 at 4:37 AM, Andrew Dunstan and...@dunslane.net wrote:
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
Re: [HACKERS] 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)
Mihai Criveti cmi...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 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)
The system and compiler are patched with the latest fix packs from IBM, and
the compiler version is the latest available.
The compiler is functional (eg: I was able to compile successfuly 64 bit
versions other software such as Apache 2.2.11, emacs 22.3, vim 7.2,
openssl-0.9.8j and so on, all with similar flags).
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.
The first build was using default options for xlC_r (the default for all IBM
compilers is -qnooptimize). ./configure seems to override this:
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
1506-396 (W) Option -qlonglong is incompatible with option -qlanglvl=extc99
and is ignored.
ld: 0711-317 ERROR: Undefined symbol: .setproctitle
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more
information.
configure:7123: $? = 8
I'll try a 32 bit build too.
On Mon, Feb 9, 2009 at 8:58 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Mihai Criveti cmi...@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
--
Criveti Mihai
http://unixsadm.blogspot.com
Re: [HACKERS] 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)
Mihai Criveti cmi...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
