Thread: AIX FAQ addition
We haven't seen any agreement emerge as to what is causing AIX 5.3 ML3 to fail to successfully build the release candidates. However, a patch has emerged (thanks, Seneca!) that does allow it to work, and which I'd expect to be portable (better still!). We are still actively pursuing why it breaks, but supposing that still remains outstanding, at least the following would allow AIX users to better survive a build... Index: FAQ_AIX =================================================================== RCS file: /projects/cvsroot/pgsql/doc/FAQ_AIX,v retrieving revision 1.13 diff -c -u -r1.13 FAQ_AIX --- FAQ_AIX 24 Oct 2005 22:30:35 -0000 1.13 +++ FAQ_AIX 2 Nov 2005 20:33:01 -0000 @@ -99,7 +99,7 @@ Last modified date 2005-09-06 If you upgrade to maintenance level 5300-03, that will include this -fix. Use the command "oslevel -r" to determine what maintenance level +fix. Use the command "oslevel -r" to determine what maintenance level you are at. --- From: Christopher Browne <cbbrowne@ca.afilias.info> @@ -113,3 +113,63 @@ http://www.faqs.org/faqs/aix-faq/part4/section-22.html http://www.han.de/~jum/aix/ldd.c +--- +From: Christopher Browne <cbbrowne@ca.afilias.info> +Date: 2005-11-02 + +On AIX 5.3 ML3 (e.g. maintenance level 5300-03), there is some problem +with the handling of the pointer to memcpy. It is speculated that +this relates to some linker bug that may have been introduced between +5300-02 and 5300-03, but we have so far been unable to track down the +cause. + +At any rate, the following patch, which "unwraps" the function +reference, has been observed to allow PG 8.1 pre-releases to pass +regression tests. + +The same behaviour (albeit with varying underlying functions to +"blame") has been observed when compiling with either GCC 4.0 or IBM +XLC. + +------------ per Seneca Cunningham ------------------- + +The following patch works on the AIX 5.3 ML3 box here and didn't cause +any problems with postgres on the x86 desktop. It's just a cleaner +version of what I tried earlier. + +*** dynahash.c.orig Tue Nov 1 19:41:42 2005 +--- dynahash.c Tue Nov 1 20:30:33 2005 +*************** +*** 670,676 **** + + + /* copy key into record */ + currBucket->hashvalue = hashvalue; +! hashp->keycopy(ELEMENTKEY(currBucket), keyPtr, keysize); + + + /* caller is expected to fill the data field on return */ + + +--- 670,687 ---- + + + /* copy key into record */ + currBucket->hashvalue = hashvalue; +! if (hashp->keycopy == memcpy) +! { +! memcpy(ELEMENTKEY(currBucket), keyPtr, keysize); +! } +! else if (hashp->keycopy == strncpy) +! { +! strncpy(ELEMENTKEY(currBucket), keyPtr, keysize); +! } +! else +! { +! hashp->keycopy(ELEMENTKEY(currBucket), keyPtr, keysize); +! } + + + /* caller is expected to fill the data field on return */ + +------------ per Seneca Cunningham ------------------- -- (reverse (concatenate 'string "moc.enworbbc" "@" "enworbbc")) http://cbbrowne.com/info/x.html Never take life seriously. Nobody gets out alive anyway.
Patch applied. Thanks. --------------------------------------------------------------------------- Chris Browne wrote: > We haven't seen any agreement emerge as to what is causing AIX 5.3 ML3 > to fail to successfully build the release candidates. > > However, a patch has emerged (thanks, Seneca!) that does allow it to > work, and which I'd expect to be portable (better still!). > > We are still actively pursuing why it breaks, but supposing that still > remains outstanding, at least the following would allow AIX users to > better survive a build... > > Index: FAQ_AIX > =================================================================== > RCS file: /projects/cvsroot/pgsql/doc/FAQ_AIX,v > retrieving revision 1.13 > diff -c -u -r1.13 FAQ_AIX > --- FAQ_AIX 24 Oct 2005 22:30:35 -0000 1.13 > +++ FAQ_AIX 2 Nov 2005 20:33:01 -0000 > @@ -99,7 +99,7 @@ > Last modified date 2005-09-06 > > If you upgrade to maintenance level 5300-03, that will include this > -fix. Use the command "oslevel -r" to determine what maintenance level > +fix. Use the command "oslevel -r" to determine what maintenance level > you are at. > --- > From: Christopher Browne <cbbrowne@ca.afilias.info> > @@ -113,3 +113,63 @@ > http://www.faqs.org/faqs/aix-faq/part4/section-22.html > > http://www.han.de/~jum/aix/ldd.c > +--- > +From: Christopher Browne <cbbrowne@ca.afilias.info> > +Date: 2005-11-02 > + > +On AIX 5.3 ML3 (e.g. maintenance level 5300-03), there is some problem > +with the handling of the pointer to memcpy. It is speculated that > +this relates to some linker bug that may have been introduced between > +5300-02 and 5300-03, but we have so far been unable to track down the > +cause. > + > +At any rate, the following patch, which "unwraps" the function > +reference, has been observed to allow PG 8.1 pre-releases to pass > +regression tests. > + > +The same behaviour (albeit with varying underlying functions to > +"blame") has been observed when compiling with either GCC 4.0 or IBM > +XLC. > + > +------------ per Seneca Cunningham ------------------- > + > +The following patch works on the AIX 5.3 ML3 box here and didn't cause > +any problems with postgres on the x86 desktop. It's just a cleaner > +version of what I tried earlier. > + > +*** dynahash.c.orig Tue Nov 1 19:41:42 2005 > +--- dynahash.c Tue Nov 1 20:30:33 2005 > +*************** > +*** 670,676 **** > + > + > + /* copy key into record */ > + currBucket->hashvalue = hashvalue; > +! hashp->keycopy(ELEMENTKEY(currBucket), keyPtr, keysize); > + > + > + /* caller is expected to fill the data field on return */ > + > + > +--- 670,687 ---- > + > + > + /* copy key into record */ > + currBucket->hashvalue = hashvalue; > +! if (hashp->keycopy == memcpy) > +! { > +! memcpy(ELEMENTKEY(currBucket), keyPtr, keysize); > +! } > +! else if (hashp->keycopy == strncpy) > +! { > +! strncpy(ELEMENTKEY(currBucket), keyPtr, keysize); > +! } > +! else > +! { > +! hashp->keycopy(ELEMENTKEY(currBucket), keyPtr, keysize); > +! } > + > + > + /* caller is expected to fill the data field on return */ > + > +------------ per Seneca Cunningham ------------------- > > -- > (reverse (concatenate 'string "moc.enworbbc" "@" "enworbbc")) > http://cbbrowne.com/info/x.html > Never take life seriously. Nobody gets out alive anyway. > > ---------------------------(end of broadcast)--------------------------- > TIP 6: explain analyze is your friend > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Chris Browne wrote: > We haven't seen any agreement emerge as to what is causing AIX 5.3 ML3 > to fail to successfully build the release candidates. > > However, a patch has emerged (thanks, Seneca!) that does allow it to > work, and which I'd expect to be portable (better still!). > > We are still actively pursuing why it breaks, but supposing that still > remains outstanding, at least the following would allow AIX users to > better survive a build... I can confirm that with that patch applied 8.1RC1 builds and passes a complete run of the buildfarm-script(including plpython and with a simple makefile-fix plperl) compiled with gcc 4.0.2 and xlc. So I think we should definitly add this to the FAQ at least. Stefan
Stefan Kaltenbrunner wrote: > Chris Browne wrote: > > We haven't seen any agreement emerge as to what is causing AIX 5.3 ML3 > > to fail to successfully build the release candidates. > > > > However, a patch has emerged (thanks, Seneca!) that does allow it to > > work, and which I'd expect to be portable (better still!). > > > > We are still actively pursuing why it breaks, but supposing that still > > remains outstanding, at least the following would allow AIX users to > > better survive a build... > > I can confirm that with that patch applied 8.1RC1 builds and passes a > complete run of the buildfarm-script(including plpython and with a > simple makefile-fix plperl) compiled with gcc 4.0.2 and xlc. > > So I think we should definitly add this to the FAQ at least. > Done. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
> Chris Browne wrote:
>> We haven't seen any agreement emerge as to what is causing AIX 5.3 ML3
>> to fail to successfully build the release candidates.
>>
>> However, a patch has emerged (thanks, Seneca!) that does allow it to
>> work, and which I'd expect to be portable (better still!).
>>
>> We are still actively pursuing why it breaks, but supposing that still
>> remains outstanding, at least the following would allow AIX users to
>> better survive a build...
>
> I can confirm that with that patch applied 8.1RC1 builds and passes a
> complete run of the buildfarm-script(including plpython and with a
> simple makefile-fix plperl) compiled with gcc 4.0.2 and xlc.
>
> So I think we should definitly add this to the FAQ at least.
Actually, there is a reason NOT to apply the patch in general on all
platforms; it introduces logic (an if {} else {} statement) in a place
where there wasn't previously one, which *presumably* slows things
down somewhat. I don't know if the memcpy() calls are invoked so
often as to make this material; it's hard to tell.
--
(reverse (concatenate 'string "moc.liamg" "@" "enworbbc"))
http://linuxfinances.info/info/wp.html
"Whenever you find that you are on the side of the majority, it is
time to reform." -- Mark Twain
Christopher Browne wrote:
>Actually, there is a reason NOT to apply the patch in general on all
>platforms; it introduces logic (an if {} else {} statement) in a place
>where there wasn't previously one, which *presumably* slows things
>down somewhat. I don't know if the memcpy() calls are invoked so
>often as to make this material; it's hard to tell.
>
>
That's why they invented #ifdef ;-)
Of course, the patch is more than somewhat strange anyway. I don't think
it should be applied unless we actually know what's going on.
cheers
andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> Of course, the patch is more than somewhat strange anyway. I don't think
> it should be applied unless we actually know what's going on.
Yeah. Just the first question it raises is: what else is broken,
and where?
regards, tom lane