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
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 |