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)

From: Mihai Criveti <cmihai(at)boreas(dot)ro>
To: pgsql-hackers(at)postgresql(dot)org
Subject: 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)
Date: 2009-02-09 14:41:52
Message-ID: 22c159aa0902090641x776a29c9w6da143e59f3a74e0@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 <cmihai(at)boreas(dot)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(dot)Zeugswetter(at)s-itsolutions(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2009-02-09 15:13:02 Re: Hot standby, recovery infra
Previous Message Marko Kreen 2009-02-09 14:40:57 Re: WIP: fix SET WITHOUT OIDS, add SET WITH OIDS