Re: AIX FAQ addition

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Chris Browne <cbbrowne(at)acm(dot)org>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: AIX FAQ addition
Date: 2005-11-04 18:16:51
Message-ID: 200511041816.jA4IGpe16689@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches


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(at)ca(dot)afilias(dot)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(at)ca(dot)afilias(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2005-11-04 18:54:04 Re: Reducing the overhead of NUMERIC data
Previous Message mark 2005-11-04 18:10:03 Re: Reducing the overhead of NUMERIC data