Обсуждение: Fwd: Re: Compile fails on AIX 6.1
Sorry, here is my message for the mailing list. > ---------- Urspr=C3=BCngliche Nachricht ---------- > Von: "Lars Ewald (web.de)" <l.ewald-web@lars-ewald.de> > An: Tom Lane <tgl@sss.pgh.pa.us> > Datum: 14. Juli 2014 um 17:23 > Betreff: Re: [BUGS] Compile fails on AIX 6.1 >=20 > Hello Tom, >=20 > > >> PPC what exactly? >=20 > PowerPC_POWER5: > System Model: IBM,9110-51A > Machine Serial Number: ********* > Processor Type: PowerPC_POWER5 > Processor Implementation Mode: POWER 5 > Processor Version: PV_5_2 > Number Of Processors: 4 > Processor Clock Speed: 1499 MHz > CPU Type: 64-bit > Kernel Type: 64-bit > LPAR Info: 1 ********** > Memory Size: 7936 MB > Good Memory Size: 7936 MB > Platform Firmware level: SF240_418 > Firmware Version: IBM,SF240_418 > Full Core: false >=20 >=20 >=20 > Would it help to use a POWER7 system as followed? > System Model: IBM,8202-E4C > Machine Serial Number: ********* > Processor Type: PowerPC_POWER7 > Processor Implementation Mode: POWER 7 > Processor Version: PV_7_Compat > Number Of Processors: 4 > Processor Clock Speed: 3024 MHz > CPU Type: 64-bit > Kernel Type: 64-bit > LPAR Info: 15 ************ > Memory Size: 8192 MB > Good Memory Size: 8192 MB > Platform Firmware level: AL740_126 > Firmware Version: IBM,AL740_100 > Full Core: false >=20 >=20 > > Still, configure should have caught that. Does configure end up > > defining HAVE_PPC_LWARX_MUTEX_HINT in src/include/pg_config.h? >=20 > Yes, I HAVE_PPC_LWARX_MUTEX_HINT was defined. >=20 > [...] > /* Define to 1 if you have the POSIX signal interface. */ > #define HAVE_POSIX_SIGNALS /**/ >=20 > /* Define to 1 if the assembler supports PPC's LWARX mutex hint bit. */ > #define HAVE_PPC_LWARX_MUTEX_HINT 1 >=20 > /* Define to 1 if you have the `pstat' function. */ > /* #undef HAVE_PSTAT */ >=20 > /* Define to 1 if the PS_STRINGS thing exists. */ > /* #undef HAVE_PS_STRINGS */ > [...] >=20 >=20 >=20 > > Assuming that HAVE_PPC_LWARX_MUTEX_HINT is *not* getting set, > > I'd suggest commenting out the #define for USE_PPC_LWSYNC in > > pg_config_manual.h and see if it gets better. If that is the > > answer then I guess we will need a configure-time test for lwsync > > support after all. >=20 > Commenting out USE_PPC_LWSYNC did not help. Also, commenting > USE_PPC_LWSYNC out and set HAVE_PPC_LWARX_MUTEX_HINT to "0", was > not successful. >=20 >=20 > Best regards > Lars >=20 >=20 >=20 > > Tom Lane <tgl@sss.pgh.pa.us> hat am 11. Juli 2014 um 16:55 geschrieben= : > > > > > > [ please keep the mailing list cc'd ] > > > > "Lars Ewald (web.de)" <l.ewald-web@lars-ewald.de> writes: > > > Thank you for answering very fast. > > > > >> PPC what exactly? > > > > > chrp with 64-bit. > > > MACHINE_ARCHITECTURE: chrp > > > HARDWARE_BITMODE: 64 > > > > > Do you need further information regarding the system? > > > > Yes, please; CHRP is pretty non-specific as regards the processor > > generation. However, it's probably *old* since CHRP wasn't too > > successful according to Wikipedia. If the CPU predates POWER6 or > > thereabouts, then lack of LWARX hint support in the assembler > > wouldn't be surprising. > > > > Still, configure should have caught that. Does configure end up > > defining HAVE_PPC_LWARX_MUTEX_HINT in src/include/pg_config.h? > > > > Hmm ... looking at s_lock.h some more, I wonder if maybe it's > > LWSYNC and not LWARX that's causing the problem. We currently > > set USE_PPC_LWSYNC for any PPC64 build (see pg_config_manual.h). > > IIRC we knew that there were a few machines for which that heuristic > > would fail, but we didn't think anybody would be using Postgres > > on them. > > > > Assuming that HAVE_PPC_LWARX_MUTEX_HINT is *not* getting set, > > I'd suggest commenting out the #define for USE_PPC_LWSYNC in > > pg_config_manual.h and see if it gets better. If that is the > > answer then I guess we will need a configure-time test for lwsync > > support after all. > > > > >> I think the odds are pretty high that the problem here is that we t= ried > > >> to > > >> use the "mutex hint" option in our PPC spinlock assembly code, and = the > > >> system's assembler doesn't recognize that. > > > > > Would it help to use another compiler, e.g. XL C? > > > > It'd be worth trying if you have another one at hand, but it's > > hard to say what the results would be. > > > > Note that there's a question here not only as to whether it will > > build, but whether it will run on your hardware. I'd definitely > > try "make check" before believing that you have a working build. > > > > >> However, we only try to use that option after the configure script = has > > >> confirmed that the syntax is > > >> accepted, so it's not real clear how you got this result. Perhaps y= ou > > >> tried to change compilers without redoing the configure run? > > > > > No. I did not change the compiler. By the way, I always run "make cl= ean" > > > and > > > then re"configure" > > > to recompile the code. > > > > That might be good enough, but personally I always do "make distclean" > > before reconfiguring. > > > > regards, tom lane >=20
Hello, could you try IBM XLC/C++ instead of gcc? Bye Rainer On 15.07.2014 18:51, Lars Ewald (web.de) wrote: > Sorry, here is my message for the mailing list. >> ---------- Ursprüngliche Nachricht ---------- >> Von: "Lars Ewald (web.de)" <l.ewald-web@lars-ewald.de> >> An: Tom Lane <tgl@sss.pgh.pa.us> >> Datum: 14. Juli 2014 um 17:23 >> Betreff: Re: [BUGS] Compile fails on AIX 6.1 >> >> Hello Tom, >> >> > >> PPC what exactly? >> >> PowerPC_POWER5: >> System Model: IBM,9110-51A >> Machine Serial Number: ********* >> Processor Type: PowerPC_POWER5 >> Processor Implementation Mode: POWER 5 >> Processor Version: PV_5_2 >> Number Of Processors: 4 >> Processor Clock Speed: 1499 MHz >> CPU Type: 64-bit >> Kernel Type: 64-bit >> LPAR Info: 1 ********** >> Memory Size: 7936 MB >> Good Memory Size: 7936 MB >> Platform Firmware level: SF240_418 >> Firmware Version: IBM,SF240_418 >> Full Core: false >> >> >> >> Would it help to use a POWER7 system as followed? >> System Model: IBM,8202-E4C >> Machine Serial Number: ********* >> Processor Type: PowerPC_POWER7 >> Processor Implementation Mode: POWER 7 >> Processor Version: PV_7_Compat >> Number Of Processors: 4 >> Processor Clock Speed: 3024 MHz >> CPU Type: 64-bit >> Kernel Type: 64-bit >> LPAR Info: 15 ************ >> Memory Size: 8192 MB >> Good Memory Size: 8192 MB >> Platform Firmware level: AL740_126 >> Firmware Version: IBM,AL740_100 >> Full Core: false >> >> >> > Still, configure should have caught that. Does configure end up >> > defining HAVE_PPC_LWARX_MUTEX_HINT in src/include/pg_config.h? >> >> Yes, I HAVE_PPC_LWARX_MUTEX_HINT was defined. >> >> [...] >> /* Define to 1 if you have the POSIX signal interface. */ >> #define HAVE_POSIX_SIGNALS /**/ >> >> /* Define to 1 if the assembler supports PPC's LWARX mutex hint bit. */ >> #define HAVE_PPC_LWARX_MUTEX_HINT 1 >> >> /* Define to 1 if you have the `pstat' function. */ >> /* #undef HAVE_PSTAT */ >> >> /* Define to 1 if the PS_STRINGS thing exists. */ >> /* #undef HAVE_PS_STRINGS */ >> [...] >> >> >> >> > Assuming that HAVE_PPC_LWARX_MUTEX_HINT is *not* getting set, >> > I'd suggest commenting out the #define for USE_PPC_LWSYNC in >> > pg_config_manual.h and see if it gets better. If that is the >> > answer then I guess we will need a configure-time test for lwsync >> > support after all. >> >> Commenting out USE_PPC_LWSYNC did not help. Also, commenting >> USE_PPC_LWSYNC out and set HAVE_PPC_LWARX_MUTEX_HINT to "0", was >> not successful. >> >> >> Best regards >> Lars >> >> >> >> > Tom Lane <tgl@sss.pgh.pa.us> hat am 11. Juli 2014 um 16:55 >> geschrieben: >> > >> > >> > [ please keep the mailing list cc'd ] >> > >> > "Lars Ewald (web.de)" <l.ewald-web@lars-ewald.de> writes: >> > > Thank you for answering very fast. >> > >> > >> PPC what exactly? >> > >> > > chrp with 64-bit. >> > > MACHINE_ARCHITECTURE: chrp >> > > HARDWARE_BITMODE: 64 >> > >> > > Do you need further information regarding the system? >> > >> > Yes, please; CHRP is pretty non-specific as regards the processor >> > generation. However, it's probably *old* since CHRP wasn't too >> > successful according to Wikipedia. If the CPU predates POWER6 or >> > thereabouts, then lack of LWARX hint support in the assembler >> > wouldn't be surprising. >> > >> > Still, configure should have caught that. Does configure end up >> > defining HAVE_PPC_LWARX_MUTEX_HINT in src/include/pg_config.h? >> > >> > Hmm ... looking at s_lock.h some more, I wonder if maybe it's >> > LWSYNC and not LWARX that's causing the problem. We currently >> > set USE_PPC_LWSYNC for any PPC64 build (see pg_config_manual.h). >> > IIRC we knew that there were a few machines for which that heuristic >> > would fail, but we didn't think anybody would be using Postgres >> > on them. >> > >> > Assuming that HAVE_PPC_LWARX_MUTEX_HINT is *not* getting set, >> > I'd suggest commenting out the #define for USE_PPC_LWSYNC in >> > pg_config_manual.h and see if it gets better. If that is the >> > answer then I guess we will need a configure-time test for lwsync >> > support after all. >> > >> > >> I think the odds are pretty high that the problem here is that >> we tried to >> > >> use the "mutex hint" option in our PPC spinlock assembly code, >> and the >> > >> system's assembler doesn't recognize that. >> > >> > > Would it help to use another compiler, e.g. XL C? >> > >> > It'd be worth trying if you have another one at hand, but it's >> > hard to say what the results would be. >> > >> > Note that there's a question here not only as to whether it will >> > build, but whether it will run on your hardware. I'd definitely >> > try "make check" before believing that you have a working build. >> > >> > >> However, we only try to use that option after the configure >> script has >> > >> confirmed that the syntax is >> > >> accepted, so it's not real clear how you got this result. >> Perhaps you >> > >> tried to change compilers without redoing the configure run? >> > >> > > No. I did not change the compiler. By the way, I always run "make >> clean" and >> > > then re"configure" >> > > to recompile the code. >> > >> > That might be good enough, but personally I always do "make distclean" >> > before reconfiguring. >> > >> > regards, tom lane > >
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
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
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 > >
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
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 > >
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> hat am 15. Juli 2014 um > 18:51 geschrieben: >=20 > Sorry, here is my message for the mailing list. >=20 > > > ---------- Urspr=C3=BCngliche Nachricht ---------- > > Von: "Lars Ewald (web.de)" <l.ewald-web@lars-ewald.de> > > An: Tom Lane <tgl@sss.pgh.pa.us> > > Datum: 14. Juli 2014 um 17:23 > > Betreff: Re: [BUGS] Compile fails on AIX 6.1 > >=20 > > Hello Tom, > >=20 > > > >> PPC what exactly? > >=20 > > PowerPC_POWER5: > > System Model: IBM,9110-51A > > Machine Serial Number: ********* > > Processor Type: PowerPC_POWER5 > > Processor Implementation Mode: POWER 5 > > Processor Version: PV_5_2 > > Number Of Processors: 4 > > Processor Clock Speed: 1499 MHz > > CPU Type: 64-bit > > Kernel Type: 64-bit > > LPAR Info: 1 ********** > > Memory Size: 7936 MB > > Good Memory Size: 7936 MB > > Platform Firmware level: SF240_418 > > Firmware Version: IBM,SF240_418 > > Full Core: false > >=20 > >=20 > >=20 > > Would it help to use a POWER7 system as followed? > > System Model: IBM,8202-E4C > > Machine Serial Number: ********* > > Processor Type: PowerPC_POWER7 > > Processor Implementation Mode: POWER 7 > > Processor Version: PV_7_Compat > > Number Of Processors: 4 > > Processor Clock Speed: 3024 MHz > > CPU Type: 64-bit > > Kernel Type: 64-bit > > LPAR Info: 15 ************ > > Memory Size: 8192 MB > > Good Memory Size: 8192 MB > > Platform Firmware level: AL740_126 > > Firmware Version: IBM,AL740_100 > > Full Core: false > >=20 > >=20 > > > Still, configure should have caught that. Does configure end up > > > defining HAVE_PPC_LWARX_MUTEX_HINT in src/include/pg_config.h? > >=20 > > Yes, I HAVE_PPC_LWARX_MUTEX_HINT was defined. > >=20 > > [...] > > /* Define to 1 if you have the POSIX signal interface. */ > > #define HAVE_POSIX_SIGNALS /**/ > >=20 > > /* Define to 1 if the assembler supports PPC's LWARX mutex hint bit. = */ > > #define HAVE_PPC_LWARX_MUTEX_HINT 1 > >=20 > > /* Define to 1 if you have the `pstat' function. */ > > /* #undef HAVE_PSTAT */ > >=20 > > /* Define to 1 if the PS_STRINGS thing exists. */ > > /* #undef HAVE_PS_STRINGS */ > > [...] > >=20 > >=20 > >=20 > > > Assuming that HAVE_PPC_LWARX_MUTEX_HINT is *not* getting set, > > > I'd suggest commenting out the #define for USE_PPC_LWSYNC in > > > pg_config_manual.h and see if it gets better. If that is the > > > answer then I guess we will need a configure-time test for lwsync > > > support after all. > >=20 > > Commenting out USE_PPC_LWSYNC did not help. Also, commenting > > USE_PPC_LWSYNC out and set HAVE_PPC_LWARX_MUTEX_HINT to "0", was > > not successful. > >=20 > >=20 > > Best regards > > Lars > >=20 > >=20 > >=20 > > > Tom Lane <tgl@sss.pgh.pa.us> hat am 11. Juli 2014 um 16:55 geschrie= ben: > > > > > > > > > [ please keep the mailing list cc'd ] > > > > > > "Lars Ewald (web.de)" <l.ewald-web@lars-ewald.de> writes: > > > > Thank you for answering very fast. > > > > > > >> PPC what exactly? > > > > > > > chrp with 64-bit. > > > > MACHINE_ARCHITECTURE: chrp > > > > HARDWARE_BITMODE: 64 > > > > > > > Do you need further information regarding the system? > > > > > > Yes, please; CHRP is pretty non-specific as regards the processor > > > generation. However, it's probably *old* since CHRP wasn't too > > > successful according to Wikipedia. If the CPU predates POWER6 or > > > thereabouts, then lack of LWARX hint support in the assembler > > > wouldn't be surprising. > > > > > > Still, configure should have caught that. Does configure end up > > > defining HAVE_PPC_LWARX_MUTEX_HINT in src/include/pg_config.h? > > > > > > Hmm ... looking at s_lock.h some more, I wonder if maybe it's > > > LWSYNC and not LWARX that's causing the problem. We currently > > > set USE_PPC_LWSYNC for any PPC64 build (see pg_config_manual.h). > > > IIRC we knew that there were a few machines for which that heuristi= c > > > would fail, but we didn't think anybody would be using Postgres > > > on them. > > > > > > Assuming that HAVE_PPC_LWARX_MUTEX_HINT is *not* getting set, > > > I'd suggest commenting out the #define for USE_PPC_LWSYNC in > > > pg_config_manual.h and see if it gets better. If that is the > > > answer then I guess we will need a configure-time test for lwsync > > > support after all. > > > > > > >> I think the odds are pretty high that the problem here is that w= e > > > >> tried to > > > >> use the "mutex hint" option in our PPC spinlock assembly code, a= nd > > > >> the > > > >> system's assembler doesn't recognize that. > > > > > > > Would it help to use another compiler, e.g. XL C? > > > > > > It'd be worth trying if you have another one at hand, but it's > > > hard to say what the results would be. > > > > > > Note that there's a question here not only as to whether it will > > > build, but whether it will run on your hardware. I'd definitely > > > try "make check" before believing that you have a working build. > > > > > > >> However, we only try to use that option after the configure scri= pt > > > >> has > > > >> confirmed that the syntax is > > > >> accepted, so it's not real clear how you got this result. Perhap= s you > > > >> tried to change compilers without redoing the configure run? > > > > > > > No. I did not change the compiler. By the way, I always run "make > > > > clean" and > > > > then re"configure" > > > > to recompile the code. > > > > > > That might be good enough, but personally I always do "make distcle= an" > > > before reconfiguring. > > > > > > regards, tom lane > >=20 > > >=20 >=20 >=20
"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
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 > >
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
>>
>>
>
>
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
>>
>>
>
>
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
>>
>>
>
>
Hello Rainer, > What PostgreSQl exact version are you trying to compile? 9.3.4 Bye, Lars > Rainer Tammer <pgsql@spg.schulergroup.com> hat am 28. Juli 2014 um 07:58 > geschrieben: > > > 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 > > > > >
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 > Tom Lane <tgl@sss.pgh.pa.us> hat am 26. Juli 2014 um 00:32 geschrieben: > > > "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
"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
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 On 01.08.2014 19:59, Lars Ewald (web.de) wrote: > 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 > > > Tom Lane <tgl@sss.pgh.pa.us> hat am 26. Juli 2014 um 00:32 geschrieben: > > > > > > "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