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

Re: [HACKERS] Re: [PATCHES] patches for 6.2.1p6

From: "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu>
To: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
Cc: The Hermit Hacker <scrappy(at)hub(dot)org>, dg(at)illustra(dot)com, dz(at)cs(dot)unitn(dot)it, hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] Re: [PATCHES] patches for 6.2.1p6
Date: 1998-03-17 03:46:30
Message-ID: 350DF216.C8E3E3C7@alumni.caltech.edu (view raw or flat)
Thread:
Lists: pgsql-hackers
> > Can you submit an appropriate patch that can be included in the 
> > mega-patch to be created on Sunday?
> 
> Just a warning that this is not going to be easy.  We have OS-specific
> code for spinlocks in include/storage/s_lock.h and
> backend/storage/buffer/s_lock.c.  So each S_LOCK macro call has to
> have its test-and-set logic de-coupled with its 
> while-lock-fail-try-again logic. 
> Most of them are easy, but some like VAX:
> 
> #define S_LOCK(addr)        __asm__("1: bbssi $0,(%0),1b": :"r"(addr))
> 
> are hard to de-couple.  Now, I did not know we supported NetBSD on 
> VAX. Does it work, anyone?  Can I remove it?

NetBSD on VAX in on our supported list, and was verified for v6.3 by Tom
Helbekkmo.

> This is going to be pretty tough to test on every platform we support,
> so if it is done now, it will have to be done carefully.

Is this behavior in v6.2.x? In any case, if it is anything but minimally
trivial, it should be given a test on every supported platform, since it
hits the heart of the platform-specific code, doesn't it? Seems like it
should be put into the CVS tree and shaken out until the next release...

                 - Tom

In response to

Responses

pgsql-hackers by date

Next:From: The Hermit HackerDate: 1998-03-17 03:49:04
Subject: Re: [HACKERS] Re: [PATCHES] patches for 6.2.1p6
Previous:From: Bruce MomjianDate: 1998-03-17 03:21:53
Subject: Re: [HACKERS] Re: [QUESTIONS] UPDATE statement ORACLE 6 compatible

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