Re: SGI Port of Postgresql 6.4 snapshot of 09/28/98

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: bruc(at)pluto(dot)njcc(dot)com (Robert Bruccoleri)
Cc: pgsql-hackers(at)hub(dot)org, scrappy(at)hub(dot)org
Subject: Re: SGI Port of Postgresql 6.4 snapshot of 09/28/98
Date: 1998-10-02 16:17:05
Message-ID: 199810021617.MAA10153@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I have applied patches 2, 3, and 4. For patch 1, I changed the 'long
long' in va_arg() to a typedef for 'long long'. Let me know if that
fixes it.

> Gentlemen:
> I have tested today's snapshot (retrieved this morning)
> on an SGI Irix 6.2 system with the following results:
>
> 1) The int8 test still fails because the SGI C compiler does
> not handle a variable argument declaration of "long long" correctly in
> the definition of the function dopr in snprintf.c. According to the
> SGI documentation, the handling of "long long" is undefined. I think
> the best solution is to use sprintf in int8.c, because there is no
> additional value to using snprintf in this context. There is no risk
> over buffer overflow in int8.c because the maximum length of a
> possible result is known in advance (21 characters + one for the null
> termination). I've modified int8.c on my machine accordingly.
> 2) The definition of the slock_t type is incorrect in irix5.h.
> 3) The new locking mechanism using test_and_set subroutine
> calls was tested by running 5 parallel processes, two creating indices
> and three doing sequential scans. All queries completed normally.
> 4) The comment in s_lock.h on possible future SGI locking
> mechanisms should be deleted, since this mechanism is fast, works, and
> is supported by SGI.
> Patches to make these corrections (except 4) are included below.

>
> Also, please include the following Makefile.custom into
> the SGI Irix FAQ:
>
> CUSTOM_CC = cc -32 -g
> LD += -32 -g
>
> The "-32" switch is essential, but I haven't tested the need for "-g".
> If I have time before the release, I will report the results. At least,
> I know that this version passes the regression tests.

Please contact the IRIX FAQ maintainer directly.

>
> Would you please put my name on the list of people who
> contributed to the 6.4 release? Thanks.

Done.

>
> Here are the patches:
>
> *** backend/utils/adt/int8.c.orig Tue Sep 1 03:01:35 1998
> --- backend/utils/adt/int8.c Mon Sep 28 21:32:38 1998
> ***************
> *** 66,74 ****
> if (!PointerIsValid(val))
> return NULL;
>
> ! if ((len = snprintf(buf, MAXINT8LEN, INT64_FORMAT, *val)) < 0)
> elog(ERROR, "Unable to format int8", NULL);
> -
> result = palloc(len + 1);
>
> strcpy(result, buf);
> --- 66,73 ----
> if (!PointerIsValid(val))
> return NULL;
>
> ! if ((len = sprintf(buf, INT64_FORMAT, *val)) < 0)
> elog(ERROR, "Unable to format int8", NULL);
> result = palloc(len + 1);
>
> strcpy(result, buf);
> *** include/port/irix5.h.orig Sun Sep 7 00:59:54 1997
> --- include/port/irix5.h Mon Sep 28 19:37:12 1998
> ***************
> *** 3,7 ****
> #define NO_EMPTY_STMTS
> #define SYSV_DIRENT
> #define HAS_TEST_AND_SET
> ! #include <abi_mutex.h>
> ! typedef abilock_t slock_t;
> --- 3,6 ----
> #define NO_EMPTY_STMTS
> #define SYSV_DIRENT
> #define HAS_TEST_AND_SET
> ! typedef unsigned long slock_t;
> *** include/storage/s_lock.h.orig Mon Sep 21 03:00:17 1998
> --- include/storage/s_lock.h Mon Sep 28 19:37:12 1998
> ***************
> *** 259,266 ****
> #if defined(__sgi)
> /*
> * SGI IRIX 5
> ! * slock_t is defined as a struct abilock_t, which has a single unsigned long
> ! * member.
> *
> * This stuff may be supplemented in the future with Masato Kataoka's MIPS-II
> * assembly from his NECEWS SVR4 port, but we probably ought to retain this
> --- 259,269 ----
> #if defined(__sgi)
> /*
> * SGI IRIX 5
> ! * slock_t is defined as a unsigned long. We use the standard SGI
> ! * mutex API.
> ! *
> ! * The following comment is left for historical reasons, but is probably
> ! * not a good idea since the mutex ABI is supported.
> *
> * This stuff may be supplemented in the future with Masato Kataoka's MIPS-II
> * assembly from his NECEWS SVR4 port, but we probably ought to retain this
>
> +------------------------------------------+------------------------------+
> | Robert E. Bruccoleri, Ph.D. | Associate Research Professor |
> | phone: 732 235 5796 | Center for Advanced |
> | Fax: 732 235 4850 | Biotechnology and Medicine |
> | email: bruc(at)acm(dot)org | Rutgers University |
> | URL: http://www.cabm.rutgers.edu/~bruc | 679 Hoes Lane |
> | | Piscataway, NJ 08854-5638 |
> +------------------------------------------+------------------------------+
>

--
Bruce Momjian | http://www.op.net/~candle
maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas G. Lockhart 1998-10-02 16:21:33 Re: [HACKERS] SQL92
Previous Message Bruce Momjian 1998-10-02 16:09:06 Re: [HACKERS] SQL92