Fwd: Re: Compile fails on AIX 6.1

Hello,
could you try IBM XLC/C++ instead of gcc?

Bye
Rainer

Hello,
The PostgreSQL release 9.2.7 do build on AIX 7.1 TL3 SP3 on a Power 8
machine without a problem:

bash ./configure \
--with-includes=/opt/freeware/include/readline \
--with-libraries=/opt/freeware/lib \
--prefix=/usr/local/pgsql-9.2.7 \
--with-CC=cc_r \
--without-tcl \
--without-python

../../../src/test/regress/pg_regress --inputdir=.
--temp-install=./tmp_check --top-builddir=../../.. --dlpath=.
--schedule=./parallel_schedule
============== creating temporary installation ==============
============== initializing database system ==============
============== starting postmaster ==============
running on port 57439 with PID 13369528
============== creating database "regression" ==============
CREATE DATABASE
ALTER DATABASE
============== running regression test queries ==============
test tablespace ... ok
parallel group (18 tests): char name int2 oid int4 varchar txid float4
text boolean float8 money int8 bit uuid enum numeric rangetypes
boolean ... ok
char ... ok
name ... ok
varchar ... ok
text ... ok
int2 ... ok
int4 ... ok
int8 ... ok
oid ... ok
float4 ... ok
float8 ... ok
bit ... ok
numeric ... ok
txid ... ok
uuid ... ok
enum ... ok
money ... ok
rangetypes ... ok
test strings ... ok
test numerology ... ok
parallel group (19 tests): path lseg point circle time timetz box
polygon reltime abstime tinterval comments macaddr interval date tstypes
inet timestamp timestamptz
point ... ok
lseg ... ok
box ... ok
path ... ok
polygon ... ok
circle ... ok
date ... ok
time ... ok
timetz ... ok
timestamp ... ok
timestamptz ... ok
interval ... ok
abstime ... ok
reltime ... ok
tinterval ... ok
inet ... ok
macaddr ... ok
tstypes ... ok
comments ... ok
parallel group (6 tests): geometry horology regex type_sanity oidjoins
opr_sanity
geometry ... ok
horology ... ok
regex ... ok
oidjoins ... ok
type_sanity ... ok
opr_sanity ... ok
test insert ... ok
test create_function_1 ... ok
test create_type ... ok
test create_table ... ok
test create_function_2 ... ok
parallel group (2 tests): copyselect copy
copy ... ok
copyselect ... ok
parallel group (2 tests): create_operator create_misc
create_misc ... ok
create_operator ... ok
parallel group (2 tests): create_view create_index
create_index ... ok
create_view ... ok
parallel group (10 tests): create_cast create_aggregate
create_function_3 drop_if_exists typed_table vacuum constraints
create_table_like triggers inherit
create_aggregate ... ok
create_function_3 ... ok
create_cast ... ok
constraints ... ok
triggers ... ok
inherit ... ok
create_table_like ... ok
typed_table ... ok
vacuum ... ok
drop_if_exists ... ok
test sanity_check ... ok
test errors ... ok
test select ... ok
parallel group (19 tests): select_distinct select_distinct_on
select_implicit select_having select_into random btree_index update case
namespace delete hash_index transactions union portals arrays aggregates
subselect join
select_into ... ok
select_distinct ... ok
select_distinct_on ... ok
select_implicit ... ok
select_having ... ok
subselect ... ok
union ... ok
case ... ok
join ... ok
aggregates ... ok
transactions ... ok
random ... ok
portals ... ok
arrays ... ok
btree_index ... ok
hash_index ... ok
update ... ok
namespace ... ok
delete ... ok
parallel group (3 tests): security_label collate privileges
privileges ... ok
security_label ... ok
collate ... ok
test misc ... ok
test rules ... ok
parallel group (16 tests): portals_p2 combocid tsdicts xmlmap
advisory_lock json guc dependency functional_deps cluster tsearch
select_views foreign_data window foreign_key bitmapops
select_views ... ok
portals_p2 ... ok
foreign_key ... ok
cluster ... ok
dependency ... ok
guc ... ok
bitmapops ... ok
combocid ... ok
tsearch ... ok
tsdicts ... ok
foreign_data ... ok
window ... ok
xmlmap ... ok
functional_deps ... ok
advisory_lock ... ok
json ... ok
parallel group (18 tests): limit conversion prepare plancache xml copy2
temp returning sequence polymorphism with domain without_oid rowtypes
rangefuncs largeobject truncate alter_table
plancache ... ok
limit ... ok
copy2 ... ok
temp ... ok
domain ... ok
rangefuncs ... ok
prepare ... ok
without_oid ... ok
conversion ... ok
truncate ... ok
alter_table ... ok
sequence ... ok
polymorphism ... ok
rowtypes ... ok
returning ... ok
largeobject ... ok
with ... ok
xml ... ok
test stats ... ok
============== shutting down postmaster ==============

=======================
All 129 tests passed.
=======================

Bye
Rainer

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Rainer Tammer <pgsql@spg.schulergroup.com> writes:

The PostgreSQL release 9.2.7 do build on AIX 7.1 TL3 SP3 on a Power 8
machine without a problem:

That's good news! I hope you will set up a buildfarm member so we can
make sure it keeps working.

regards, tom lane

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Hello,
This was a first test in that direction...

I have tried to run a parallel build, but that was not successful.
Should a parallel build (make -j n; n > 1) work?

Bye
Rainer

On 24.07.2014 19:22, Tom Lane wrote:

Rainer Tammer <pgsql@spg.schulergroup.com> writes:

The PostgreSQL release 9.2.7 do build on AIX 7.1 TL3 SP3 on a Power 8
machine without a problem:

That's good news! I hope you will set up a buildfarm member so we can
make sure it keeps working.

regards, tom lane

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Rainer Tammer <pgsql@spg.schulergroup.com> writes:

I have tried to run a parallel build, but that was not successful.
Should a parallel build (make -j n; n > 1) work?

Yes; I routinely do -j8 or so, and I think many of the buildfarm members
are configured to use -j with various multipliers. Having said that,
we have seen (and worked around) some bugs in the parallel-build support
in some versions of gmake. There might be more :-(. What make version
are you using, and what failure did you see exactly?

(Of course, you could configure a buildfarm member with -j 1 as a
first step, and worry about parallelism later ...)

regards, tom lane

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Hello,
I have used an old version:

root@aixtest06 rc:0 # gmake --version
GNU Make 3.80
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

But I can upgrade to a new version, that's no problem.
Which version do you recommend?

Bye
Rainer

On 25.07.2014 08:48, Tom Lane wrote:

Rainer Tammer <pgsql@spg.schulergroup.com> writes:

I have tried to run a parallel build, but that was not successful.
Should a parallel build (make -j n; n > 1) work?

Yes; I routinely do -j8 or so, and I think many of the buildfarm members
are configured to use -j with various multipliers. Having said that,
we have seen (and worked around) some bugs in the parallel-build support
in some versions of gmake. There might be more :-(. What make version
are you using, and what failure did you see exactly?

(Of course, you could configure a buildfarm member with -j 1 as a
first step, and worry about parallelism later ...)

regards, tom lane

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Hello Tom,

today I was able to do some tests compiling Postgres on our AIX machine.

And...it worked! :-) Configuring without spinlocks and readline worked fine for
me and did not abort after compiling xlog.o/xlog.c.
Any ideas why it does not work with spinlocks?

Best regards,
Lars

p. s. Compiling against xlC did not work. I think our xlC installation is a bit
curious. :-(

"Lars Ewald (web.de)" <l.ewald-web@lars-ewald.de> writes:

Hello Tom,
today I was able to do some tests compiling Postgres on our AIX machine.

And...it worked! :-) Configuring without spinlocks and readline worked fine for
me and did not abort after compiling xlog.o/xlog.c.
Any ideas why it does not work with spinlocks?

Well, spinlocks are what uses the assembler code that you're having
trouble with.

Note that while you can build with --disable-spinlocks, performance is
not likely to be acceptable. We don't really consider a platform
supported unless it's got working spinlocks.

regards, tom lane

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Hello,
What PostgreSQl exact version are you trying to compile?
I like to test this with the IBM compiler.

Bye
Rainer

On 26.07.2014 00:32, Tom Lane wrote:

"Lars Ewald (web.de)" <l.ewald-web@lars-ewald.de> writes:

Hello Tom,
today I was able to do some tests compiling Postgres on our AIX machine.
And...it worked! :-) Configuring without spinlocks and readline worked fine for
me and did not abort after compiling xlog.o/xlog.c.
Any ideas why it does not work with spinlocks?

Well, spinlocks are what uses the assembler code that you're having
trouble with.

Note that while you can build with --disable-spinlocks, performance is
not likely to be acceptable. We don't really consider a platform
supported unless it's got working spinlocks.

regards, tom lane

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Hello,
PostgreSQL 9.3.5 does pass all regression tests on AIX 7.1 TL3 SP3:

bash ./configure \
--with-includes=/opt/freeware/include/readline \
--with-libraries=/opt/freeware/lib \
--prefix=/usr/local/pgsql-9.3.5 \
--with-CC=cc_r \
--without-tcl \
--without-python

../../../src/test/regress/pg_regress --inputdir=.
--temp-install=./tmp_check --top-builddir=../../.. --dlpath=.
--schedule=./parallel_schedule
============== creating temporary installation ==============
============== initializing database system ==============
============== starting postmaster ==============
running on port 57537 with PID 6357156
============== creating database "regression" ==============
CREATE DATABASE
ALTER DATABASE
============== running regression test queries ==============
test tablespace ... ok
parallel group (18 tests): name char oid float4 float8 int2 int4
boolean varchar text money int8 txid bit uuid enum numeric rangetypes
boolean ... ok
char ... ok
name ... ok
varchar ... ok
text ... ok
int2 ... ok
int4 ... ok
int8 ... ok
oid ... ok
float4 ... ok
float8 ... ok
bit ... ok
numeric ... ok
txid ... ok
uuid ... ok
enum ... ok
money ... ok
rangetypes ... ok
test strings ... ok
test numerology ... ok
parallel group (19 tests): lseg point path box polygon circle time
comments timetz reltime abstime macaddr tinterval tstypes date interval
inet timestamp timestamptz
point ... ok
lseg ... ok
box ... ok
path ... ok
polygon ... ok
circle ... ok
date ... ok
time ... ok
timetz ... ok
timestamp ... ok
timestamptz ... ok
interval ... ok
abstime ... ok
reltime ... ok
tinterval ... ok
inet ... ok
macaddr ... ok
tstypes ... ok
comments ... ok
parallel group (6 tests): geometry regex horology type_sanity oidjoins
opr_sanity
geometry ... ok
horology ... ok
regex ... ok
oidjoins ... ok
type_sanity ... ok
opr_sanity ... ok
test insert ... ok
test create_function_1 ... ok
test create_type ... ok
test create_table ... ok
test create_function_2 ... ok
parallel group (2 tests): copyselect copy
copy ... ok
copyselect ... ok
parallel group (2 tests): create_operator create_misc
create_misc ... ok
create_operator ... ok
parallel group (2 tests): create_view create_index
create_index ... ok
create_view ... ok
parallel group (11 tests): create_aggregate create_cast
create_function_3 drop_if_exists typed_table vacuum constraints
create_table_like triggers updatable_views inherit
create_aggregate ... ok
create_function_3 ... ok
create_cast ... ok
constraints ... ok
triggers ... ok
inherit ... ok
create_table_like ... ok
typed_table ... ok
vacuum ... ok
drop_if_exists ... ok
updatable_views ... ok
test sanity_check ... ok
test errors ... ok
test select ... ok
parallel group (20 tests): select_distinct_on select_distinct
select_implicit select_into select_having case update btree_index random
namespace delete hash_index transactions portals union subselect
aggregates arrays join prepared_xacts
select_into ... ok
select_distinct ... ok
select_distinct_on ... ok
select_implicit ... ok
select_having ... ok
subselect ... ok
union ... ok
case ... ok
join ... ok
aggregates ... ok
transactions ... ok
random ... ok
portals ... ok
arrays ... ok
btree_index ... ok
hash_index ... ok
update ... ok
namespace ... ok
prepared_xacts ... ok
delete ... ok
parallel group (4 tests): security_label collate privileges matview
privileges ... ok
security_label ... ok
collate ... ok
matview ... ok
parallel group (3 tests): psql alter_generic misc
alter_generic ... ok
misc ... ok
psql ... ok
test rules ... ok
test event_trigger ... ok
parallel group (16 tests): portals_p2 combocid tsdicts advisory_lock
dependency xmlmap guc json functional_deps select_views cluster window
tsearch foreign_data foreign_key bitmapops
select_views ... ok
portals_p2 ... ok
foreign_key ... ok
cluster ... ok
dependency ... ok
guc ... ok
bitmapops ... ok
combocid ... ok
tsearch ... ok
tsdicts ... ok
foreign_data ... ok
window ... ok
xmlmap ... ok
functional_deps ... ok
advisory_lock ... ok
json ... ok
parallel group (19 tests): limit plancache conversion prepare xml
returning temp polymorphism copy2 sequence without_oid with rowtypes
domain largeobject rangefuncs truncate alter_table plpgsql
plancache ... ok
limit ... ok
plpgsql ... ok
copy2 ... ok
temp ... ok
domain ... ok
rangefuncs ... ok
prepare ... ok
without_oid ... ok
conversion ... ok
truncate ... ok
alter_table ... ok
sequence ... ok
polymorphism ... ok
rowtypes ... ok
returning ... ok
largeobject ... ok
with ... ok
xml ... ok
test stats ... ok
============== shutting down postmaster ==============

=======================
All 136 tests passed.
=======================

Bye
Rainer

On 25.07.2014 09:22, Rainer Tammer wrote:

Hello,
I have used an old version:

root@aixtest06 rc:0 # gmake --version
GNU Make 3.80
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

But I can upgrade to a new version, that's no problem.
Which version do you recommend?

Bye
Rainer

On 25.07.2014 08:48, Tom Lane wrote:

Rainer Tammer <pgsql@spg.schulergroup.com> writes:

I have tried to run a parallel build, but that was not successful.
Should a parallel build (make -j n; n > 1) work?

Yes; I routinely do -j8 or so, and I think many of the buildfarm members
are configured to use -j with various multipliers. Having said that,
we have seen (and worked around) some bugs in the parallel-build support
in some versions of gmake. There might be more :-(. What make version
are you using, and what failure did you see exactly?

(Of course, you could configure a buildfarm member with -j 1 as a
first step, and worry about parallelism later ...)

regards, tom lane

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Hello,
PostgreSQL 9.4 Beta 2 does pass all regression tests on AIX 7.1 TL3 SP3:

bash ./configure \
--with-includes=/opt/freeware/include/readline \
--with-libraries=/opt/freeware/lib \
--prefix=/usr/local/pgsql-9.4.b2 \
--with-CC=cc_r \ <-- IBM XLC/C++ V12
--without-tcl \
--without-python

../../../src/test/regress/pg_regress --inputdir=.
--temp-install=./tmp_check --top-builddir=../../.. --dlpath=.
--schedule=./parallel_schedule
============== creating temporary installation ==============
============== initializing database system ==============
============== starting postmaster ==============
running on port 57632 with PID 11468860
============== creating database "regression" ==============
CREATE DATABASE
ALTER DATABASE
============== running regression test queries ==============
test tablespace ... ok
parallel group (20 tests): name int4 int2 oid varchar char text float4
float8 regproc money boolean txid pg_lsn int8 bit uuid enum numeric
rangetypes
boolean ... ok
char ... ok
name ... ok
varchar ... ok
text ... ok
int2 ... ok
int4 ... ok
int8 ... ok
oid ... ok
float4 ... ok
float8 ... ok
bit ... ok
numeric ... ok
txid ... ok
uuid ... ok
enum ... ok
money ... ok
rangetypes ... ok
pg_lsn ... ok
regproc ... ok
test strings ... ok
test numerology ... ok
parallel group (20 tests): line lseg point path box polygon circle time
timetz abstime comments date tinterval reltime interval tstypes macaddr
inet timestamp timestamptz
point ... ok
lseg ... ok
line ... ok
box ... ok
path ... ok
polygon ... ok
circle ... ok
date ... ok
time ... ok
timetz ... ok
timestamp ... ok
timestamptz ... ok
interval ... ok
abstime ... ok
reltime ... ok
tinterval ... ok
inet ... ok
macaddr ... ok
tstypes ... ok
comments ... ok
parallel group (6 tests): geometry regex horology type_sanity oidjoins
opr_sanity
geometry ... ok
horology ... ok
regex ... ok
oidjoins ... ok
type_sanity ... ok
opr_sanity ... ok
test insert ... ok
test create_function_1 ... ok
test create_type ... ok
test create_table ... ok
test create_function_2 ... ok
parallel group (2 tests): copyselect copy
copy ... ok
copyselect ... ok
parallel group (2 tests): create_operator create_misc
create_misc ... ok
create_operator ... ok
parallel group (2 tests): create_view create_index
create_index ... ok
create_view ... ok
parallel group (11 tests): create_cast create_aggregate
create_function_3 drop_if_exists typed_table vacuum constraints
create_table_like triggers inherit updatable_views
create_aggregate ... ok
create_function_3 ... ok
create_cast ... ok
constraints ... ok
triggers ... ok
inherit ... ok
create_table_like ... ok
typed_table ... ok
vacuum ... ok
drop_if_exists ... ok
updatable_views ... ok
test sanity_check ... ok
test errors ... ok
test select ... ok
parallel group (20 tests): select_distinct select_distinct_on
select_implicit select_having select_into case btree_index random update
hash_index delete namespace transactions union portals subselect arrays
aggregates join prepared_xacts
select_into ... ok
select_distinct ... ok
select_distinct_on ... ok
select_implicit ... ok
select_having ... ok
subselect ... ok
union ... ok
case ... ok
join ... ok
aggregates ... ok
transactions ... ok
random ... ok
portals ... ok
arrays ... ok
btree_index ... ok
hash_index ... ok
update ... ok
namespace ... ok
prepared_xacts ... ok
delete ... ok
parallel group (6 tests): lock security_label replica_identity collate
privileges matview
privileges ... ok
security_label ... ok
collate ... ok
matview ... ok
lock ... ok
replica_identity ... ok
parallel group (4 tests): async psql alter_generic misc
alter_generic ... ok
misc ... ok
psql ... ok
async ... ok
test rules ... ok
test event_trigger ... ok
parallel group (18 tests): portals_p2 combocid tsdicts guc
advisory_lock xmlmap dependency json functional_deps cluster
select_views tsearch jsonb foreign_data window foreign_key bitmapops
indirect_toast
select_views ... ok
portals_p2 ... ok
foreign_key ... ok
cluster ... ok
dependency ... ok
guc ... ok
bitmapops ... ok
combocid ... ok
tsearch ... ok
tsdicts ... ok
foreign_data ... ok
window ... ok
xmlmap ... ok
functional_deps ... ok
advisory_lock ... ok
json ... ok
jsonb ... ok
indirect_toast ... ok
parallel group (19 tests): limit plancache conversion prepare xml
returning temp copy2 sequence polymorphism without_oid with rowtypes
domain truncate rangefuncs largeobject alter_table plpgsql
plancache ... ok
limit ... ok
plpgsql ... ok
copy2 ... ok
temp ... ok
domain ... ok
rangefuncs ... ok
prepare ... ok
without_oid ... ok
conversion ... ok
truncate ... ok
alter_table ... ok
sequence ... ok
polymorphism ... ok
rowtypes ... ok
returning ... ok
largeobject ... ok
with ... ok
xml ... ok
test stats ... ok
============== shutting down postmaster ==============

=======================
All 144 tests passed.
=======================

Bye
Rainer

On 25.07.2014 09:22, Rainer Tammer wrote:

Hello,
I have used an old version:

root@aixtest06 rc:0 # gmake --version
GNU Make 3.80
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

But I can upgrade to a new version, that's no problem.
Which version do you recommend?

Bye
Rainer

On 25.07.2014 08:48, Tom Lane wrote:

Rainer Tammer <pgsql@spg.schulergroup.com> writes:

I have tried to run a parallel build, but that was not successful.
Should a parallel build (make -j n; n > 1) work?

Yes; I routinely do -j8 or so, and I think many of the buildfarm members
are configured to use -j with various multipliers. Having said that,
we have seen (and worked around) some bugs in the parallel-build support
in some versions of gmake. There might be more :-(. What make version
are you using, and what failure did you see exactly?

(Of course, you could configure a buildfarm member with -j 1 as a
first step, and worry about parallelism later ...)

regards, tom lane

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Hello,
PostgreSQL 9.3.5 does pass all regression tests on AIX 7.1 TL3 SP3:

bash ./configure \
--with-includes=/opt/freeware/include/readline \
--with-libraries=/opt/freeware/lib \
--prefix=/usr/local/pgsql-9.3.5 \
--with-CC=cc_r \ <-- IBM XLC/C++ V12
--without-tcl \
--without-python

../../../src/test/regress/pg_regress --inputdir=.
--temp-install=./tmp_check --top-builddir=../../.. --dlpath=.
--schedule=./parallel_schedule
============== creating temporary installation ==============
============== initializing database system ==============
============== starting postmaster ==============
running on port 57537 with PID 6357156
============== creating database "regression" ==============
CREATE DATABASE
ALTER DATABASE
============== running regression test queries ==============
test tablespace ... ok
parallel group (18 tests): name char oid float4 float8 int2 int4
boolean varchar text money int8 txid bit uuid enum numeric rangetypes
boolean ... ok
char ... ok
name ... ok
varchar ... ok
text ... ok
int2 ... ok
int4 ... ok
int8 ... ok
oid ... ok
float4 ... ok
float8 ... ok
bit ... ok
numeric ... ok
txid ... ok
uuid ... ok
enum ... ok
money ... ok
rangetypes ... ok
test strings ... ok
test numerology ... ok
parallel group (19 tests): lseg point path box polygon circle time
comments timetz reltime abstime macaddr tinterval tstypes date interval
inet timestamp timestamptz
point ... ok
lseg ... ok
box ... ok
path ... ok
polygon ... ok
circle ... ok
date ... ok
time ... ok
timetz ... ok
timestamp ... ok
timestamptz ... ok
interval ... ok
abstime ... ok
reltime ... ok
tinterval ... ok
inet ... ok
macaddr ... ok
tstypes ... ok
comments ... ok
parallel group (6 tests): geometry regex horology type_sanity oidjoins
opr_sanity
geometry ... ok
horology ... ok
regex ... ok
oidjoins ... ok
type_sanity ... ok
opr_sanity ... ok
test insert ... ok
test create_function_1 ... ok
test create_type ... ok
test create_table ... ok
test create_function_2 ... ok
parallel group (2 tests): copyselect copy
copy ... ok
copyselect ... ok
parallel group (2 tests): create_operator create_misc
create_misc ... ok
create_operator ... ok
parallel group (2 tests): create_view create_index
create_index ... ok
create_view ... ok
parallel group (11 tests): create_aggregate create_cast
create_function_3 drop_if_exists typed_table vacuum constraints
create_table_like triggers updatable_views inherit
create_aggregate ... ok
create_function_3 ... ok
create_cast ... ok
constraints ... ok
triggers ... ok
inherit ... ok
create_table_like ... ok
typed_table ... ok
vacuum ... ok
drop_if_exists ... ok
updatable_views ... ok
test sanity_check ... ok
test errors ... ok
test select ... ok
parallel group (20 tests): select_distinct_on select_distinct
select_implicit select_into select_having case update btree_index random
namespace delete hash_index transactions portals union subselect
aggregates arrays join prepared_xacts
select_into ... ok
select_distinct ... ok
select_distinct_on ... ok
select_implicit ... ok
select_having ... ok
subselect ... ok
union ... ok
case ... ok
join ... ok
aggregates ... ok
transactions ... ok
random ... ok
portals ... ok
arrays ... ok
btree_index ... ok
hash_index ... ok
update ... ok
namespace ... ok
prepared_xacts ... ok
delete ... ok
parallel group (4 tests): security_label collate privileges matview
privileges ... ok
security_label ... ok
collate ... ok
matview ... ok
parallel group (3 tests): psql alter_generic misc
alter_generic ... ok
misc ... ok
psql ... ok
test rules ... ok
test event_trigger ... ok
parallel group (16 tests): portals_p2 combocid tsdicts advisory_lock
dependency xmlmap guc json functional_deps select_views cluster window
tsearch foreign_data foreign_key bitmapops
select_views ... ok
portals_p2 ... ok
foreign_key ... ok
cluster ... ok
dependency ... ok
guc ... ok
bitmapops ... ok
combocid ... ok
tsearch ... ok
tsdicts ... ok
foreign_data ... ok
window ... ok
xmlmap ... ok
functional_deps ... ok
advisory_lock ... ok
json ... ok
parallel group (19 tests): limit plancache conversion prepare xml
returning temp polymorphism copy2 sequence without_oid with rowtypes
domain largeobject rangefuncs truncate alter_table plpgsql
plancache ... ok
limit ... ok
plpgsql ... ok
copy2 ... ok
temp ... ok
domain ... ok
rangefuncs ... ok
prepare ... ok
without_oid ... ok
conversion ... ok
truncate ... ok
alter_table ... ok
sequence ... ok
polymorphism ... ok
rowtypes ... ok
returning ... ok
largeobject ... ok
with ... ok
xml ... ok
test stats ... ok
============== shutting down postmaster ==============

=======================
All 136 tests passed.
=======================

Bye
Rainer

On 25.07.2014 09:22, Rainer Tammer wrote:

Hello,
I have used an old version:

root@aixtest06 rc:0 # gmake --version
GNU Make 3.80
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

But I can upgrade to a new version, that's no problem.
Which version do you recommend?

Bye
Rainer

On 25.07.2014 08:48, Tom Lane wrote:

Rainer Tammer <pgsql@spg.schulergroup.com> writes:

I have tried to run a parallel build, but that was not successful.
Should a parallel build (make -j n; n > 1) work?

Yes; I routinely do -j8 or so, and I think many of the buildfarm members
are configured to use -j with various multipliers. Having said that,
we have seen (and worked around) some bugs in the parallel-build support
in some versions of gmake. There might be more :-(. What make version
are you using, and what failure did you see exactly?

(Of course, you could configure a buildfarm member with -j 1 as a
first step, and worry about parallelism later ...)

regards, tom lane

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Hello Tom

We don't really consider a platform
supported unless it's got working spinlocks.

I am a little bit confused about that.

On the page "supported platforms" there is written that PowerPC or PowerPC 64 is
a supported
platform, so that I can compile postgres WITH spinlocks.
http://www.postgresql.org/docs/9.3/static/supported-platforms.html

Or is there a problem on the specific machine? Or is there something disabled
in the kernel?

Best regards
Lars

Hello Rainer,

What PostgreSQl exact version are you trying to compile?

9.3.4

Bye,
Lars

"Lars Ewald (web.de)" <l.ewald-web@lars-ewald.de> writes:

We don't really consider a platform
supported unless it's got working spinlocks.

I am a little bit confused about that.

Well, so are we.

Or is there a problem on the specific machine? Or is there something disabled
in the kernel?

It seems to be a toolchain problem, ie, compiler or assembler doing
something unexpected with our PPC spinlock code. But we don't really
have enough info to diagnose. I can think of a bunch of ways it might
have gone wrong, but we seem to have eliminated all those theories :-(

regards, tom lane

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Hello,
Please try the IBM C/C++ compiler.

Could you use 9.3.5? This is the latest 9.3.x version.
I have tested 9.3.5 on AIX 6.1 and AIX 7.1 without a compilation/test
failure.

Please could you post your exact ./configure call?

Bye
Rainer

A year ago we had a thread about assembler syntax errors on AIX, but it
died off when the original complainant stopped responding. I was recently
contacted off-list by Steve Underwood, who was seeing the same symptoms
on AIX 7.1. After some investigation, we found that the problem is that
IBM's assembler doesn't understand the "local symbol" notation supported
by the GNU assembler ("bne 1f" referencing the next occurrence of "1:").
So s_lock.h's PowerPC assembly code works if you have gcc configured to
use gas as backend, but not if it's configured to use the native AIX
assembler. Steve says the latter configuration is pretty common.

Curiously, our build goes through just fine if you use the gcc 4.2.0
build available from IBM's website. But it turns out it's using the
"generic AIX" stanza of s_lock.h, ie _check_lock(), rather than the
lwarx assembly code. AFAICS this must mean that that gcc build does
not define __ppc__ --- very weird. But a bit offtopic.

So now that we know what is happening, what do we want to do about it?
AFAICS there are two plausible ways to fix it:

1. Add a configure-time test to see if the assembler supports local
symbols. If not, don't try to use the lwarx assembly stanza, but let
it fall through to using _check_lock(). This would be simple but
there would presumably be some performance hit.

2. Don't rely on local symbols in the PPC spinlock assembly code. This
is a bit ugly, because the only way to do that is to hard-code branch
offsets, as in the attached draft patch. If there were any likelihood
that we'd be changing the PPC spinlock code in future, I would regard
this as unmaintainable ... but really, that code is pretty static.
So I think this is a viable alternative.

Comments?

regards, tom lane

On Thu, Aug 27, 2015 at 10:36:46AM -0400, Tom Lane wrote:

the problem is that
IBM's assembler doesn't understand the "local symbol" notation supported
by the GNU assembler ("bne 1f" referencing the next occurrence of "1:").
So s_lock.h's PowerPC assembly code works if you have gcc configured to
use gas as backend, but not if it's configured to use the native AIX
assembler. Steve says the latter configuration is pretty common.

These days, the latter configuration is all but universal. Per the GCC
installation instructions, "The GNU Assembler has not been updated to support
AIX 6 or AIX 7."

So now that we know what is happening, what do we want to do about it?
AFAICS there are two plausible ways to fix it:

1. Add a configure-time test to see if the assembler supports local
symbols. If not, don't try to use the lwarx assembly stanza, but let
it fall through to using _check_lock(). This would be simple but
there would presumably be some performance hit.

2. Don't rely on local symbols in the PPC spinlock assembly code. This
is a bit ugly, because the only way to do that is to hard-code branch
offsets, as in the attached draft patch. If there were any likelihood
that we'd be changing the PPC spinlock code in future, I would regard
this as unmaintainable ... but really, that code is pretty static.
So I think this is a viable alternative.

A third option is to use __sync intrinsics, like we do on ARM. I like (2).

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Noah Misch <noah@leadboat.com> writes:

On Thu, Aug 27, 2015 at 10:36:46AM -0400, Tom Lane wrote:

the problem is that
IBM's assembler doesn't understand the "local symbol" notation supported
by the GNU assembler ("bne 1f" referencing the next occurrence of "1:").
So s_lock.h's PowerPC assembly code works if you have gcc configured to
use gas as backend, but not if it's configured to use the native AIX
assembler. Steve says the latter configuration is pretty common.

These days, the latter configuration is all but universal. Per the GCC
installation instructions, "The GNU Assembler has not been updated to support
AIX 6 or AIX 7."

Ouch. I'm surprised we've not gotten more complaints.

2. Don't rely on local symbols in the PPC spinlock assembly code. This
is a bit ugly, because the only way to do that is to hard-code branch
offsets, as in the attached draft patch. If there were any likelihood
that we'd be changing the PPC spinlock code in future, I would regard
this as unmaintainable ... but really, that code is pretty static.
So I think this is a viable alternative.

A third option is to use __sync intrinsics, like we do on ARM. I like (2).

I've been waiting to hear confirmation from Steve that the proposed patch
works with IBM's assembler. (For all I know, it uses "*" rather than ".",
or some other randomness.) He's not responded yet though. Are you in
a position to test the patch?

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

I wrote:

Noah Misch <noah@leadboat.com> writes:

On Thu, Aug 27, 2015 at 10:36:46AM -0400, Tom Lane wrote:

2. Don't rely on local symbols in the PPC spinlock assembly code.

A third option is to use __sync intrinsics, like we do on ARM. I like (2).

I've been waiting to hear confirmation from Steve that the proposed patch
works with IBM's assembler. (For all I know, it uses "*" rather than ".",
or some other randomness.) He's not responded yet though. Are you in
a position to test the patch?

Steve got back to me with the news that AIX's assembler thinks that "."
is an ordinary symbol, not the current location. Some googling says that
that assembler likes "$" for current location. I did a quick check on my
oldest OS X PPC box, and it seems to be happy with "$" as well, so maybe
we can use that --- though I see nothing about "$" in the GNU Assembler
manual, which makes me a bit worried about whether it works on all PPC
systems.

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

I wrote:

... that assembler likes "$" for current location. I did a quick check on my
oldest OS X PPC box, and it seems to be happy with "$" as well, so maybe
we can use that --- though I see nothing about "$" in the GNU Assembler
manual, which makes me a bit worried about whether it works on all PPC
systems.

A look into the current gas sources finds this in config/tc-ppc.h:

/* $ is used to refer to the current location. */
#define DOLLAR_DOT

so apparently this is indeed standard behavior for gas on PPC. There's
no indication that you could turn it off without manually hacking this
config header.

Source code access to one's tools is so pleasant ...

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

On Fri, Aug 28, 2015 at 09:58:46AM -0400, Tom Lane wrote:

Noah Misch <noah@leadboat.com> writes:

On Thu, Aug 27, 2015 at 10:36:46AM -0400, Tom Lane wrote:

So s_lock.h's PowerPC assembly code works if you have gcc configured to
use gas as backend, but not if it's configured to use the native AIX
assembler. Steve says the latter configuration is pretty common.

These days, the latter configuration is all but universal. Per the GCC
installation instructions, "The GNU Assembler has not been updated to support
AIX 6 or AIX 7."

Ouch. I'm surprised we've not gotten more complaints.

That surprised me, too. Perhaps almost everyone has used either xlc or that
IBM-provided gcc you wrote about.

2. Don't rely on local symbols in the PPC spinlock assembly code.

A third option is to use __sync intrinsics, like we do on ARM. I like (2).

I've been waiting to hear confirmation from Steve that the proposed patch
works with IBM's assembler. (For all I know, it uses "*" rather than ".",
or some other randomness.) He's not responded yet though. Are you in
a position to test the patch?

I tested a gcc 64-bit build. Consistent with your followup, "b .+12" doesn't
build, but "b $+12" builds and passes "make check". I am attaching the exact
diff I tested.

On GNU/Linux ppc, I get the same opcodes before and after the change.

Noah Misch <noah@leadboat.com> writes:

I tested a gcc 64-bit build. Consistent with your followup, "b .+12" doesn't
build, but "b $+12" builds and passes "make check". I am attaching the exact
diff I tested.
On GNU/Linux ppc, I get the same opcodes before and after the change.

Thanks for checking! I have some other business to attend to today, but
I'll get this committed soon.

Please consider spinning up a gcc buildfarm critter on the machine running
hornet & mandrill.

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