Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] s_lock.h busted

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: tgl(at)sss(dot)pgh(dot)pa(dot)us (Tom Lane)
Cc: pgsql-hackers(at)postgreSQL(dot)org, pgsql-patches(at)postgreSQL(dot)org
Subject: Re: [HACKERS] s_lock.h busted
Date: 1998-07-20 17:46:21
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
> The weekend's hacking on s_lock.h broke it for all platforms that
> need non-default definitions of S_UNLOCK or S_INIT_LOCK (hpux,
> alpha, a couple others).  Someone put unconditional definitions
> of those macros at the bottom of the file.  I suspect this was a
> plain old editing typo, but perhaps the intent was to put such
> definitions in one of the platform-specific #if blocks?  (If so,
> they were unnecessary anyway.)  Anyhow, the attached patch fixes
> it for hpux.

It came in from:

	Somewhere between 6.1 and 6.3 someone removed the support for the
	NS32K machine I contributed.  In any case, I now have postgresql-6.3
	running again on NetBSD/pc532, a NS32532 machine.  The following
	changes are needed relative to the src directory.  (It looks like
	support was partially removed when the files were moved from the
	src/backend/storage/.... tree to the src/include tree.)
	If you need me to get a current development version of postgresql
	for this change let me know.  Also, let me know if this code needs
	updating due to another code movement that deleted the old NS32K
	Thank you.
	Phil Nelson

Fix applied.

Bruce Momjian                          |  830 Blythe Avenue
maillist(at)candle(dot)pha(dot)pa(dot)us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

In response to

pgsql-hackers by date

Next:From: D'Arcy J.M. CainDate: 1998-07-20 19:11:23
Subject: Re: [HACKERS] Finding primary keys in a table
Previous:From: Tom LaneDate: 1998-07-20 17:12:06
Subject: s_lock.h busted

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group