Thread: Re: [COMMITTERS] 'pgsql/src/backend/storage/buffer bufmgr.c'

Re: [COMMITTERS] 'pgsql/src/backend/storage/buffer bufmgr.c'

From
Vadim Mikheev
Date:
Tom Lane wrote:
> 
> Update of /usr/local/cvsroot/pgsql/src/backend/storage/buffer
> In directory hub.org:/tmp/cvs-serv67287
> 
> Modified Files:
>         bufmgr.c
> Log Message:
> Missing semicolons in non-HAS_TEST_AND_SET code paths :-(

Thanks, Tom!
I must say that I never tested non-Has_TEST_AND_SET case.

Vadim


Vadim Mikheev <vadim@krs.ru> writes:
>> bufmgr.c
>> Log Message:
>> Missing semicolons in non-HAS_TEST_AND_SET code paths :-(

> Thanks, Tom!
> I must say that I never tested non-Has_TEST_AND_SET case.

I haven't either --- but those two places stuck out like sore thumbs
after the pgindent run...

This suggests that none of the beta-testing group uses a machine that
doesn't have TEST_AND_SET support.  I suppose that's good news about the
coverage of s_lock.h, but it makes me worry that the non-TEST_AND_SET
code hasn't even been compiled, let alone exercised.  Someone ought to
build and test a copy with TEST_AND_SET deliberately removed from the
port.h file.
        regards, tom lane


Re: [HACKERS] Re: [COMMITTERS] 'pgsql/src/backend/storage/buffer bufmgr.c'

From
The Hermit Hacker
Date:
On Sat, 29 May 1999, Tom Lane wrote:

> Vadim Mikheev <vadim@krs.ru> writes:
> >> bufmgr.c
> >> Log Message:
> >> Missing semicolons in non-HAS_TEST_AND_SET code paths :-(
> 
> > Thanks, Tom!
> > I must say that I never tested non-Has_TEST_AND_SET case.
> 
> I haven't either --- but those two places stuck out like sore thumbs
> after the pgindent run...
> 
> This suggests that none of the beta-testing group uses a machine that
> doesn't have TEST_AND_SET support.  I suppose that's good news about the
> coverage of s_lock.h, but it makes me worry that the non-TEST_AND_SET
> code hasn't even been compiled, let alone exercised.  Someone ought to
> build and test a copy with TEST_AND_SET deliberately removed from the
> port.h file.

MIght this not indicate that that code is, in fact, useless?  Designed for
older OSs that didn't have appropriate support?

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 



Re: [HACKERS] Re: [COMMITTERS] 'pgsql/src/backend/storage/bufferbufmgr.c'

From
"Henry B. Hotz"
Date:
At 3:44 PM -0700 5/29/99, The Hermit Hacker wrote:
>On Sat, 29 May 1999, Tom Lane wrote:
>> This suggests that none of the beta-testing group uses a machine that
>> doesn't have TEST_AND_SET support.  I suppose that's good news about the
>> coverage of s_lock.h, but it makes me worry that the non-TEST_AND_SET
>> code hasn't even been compiled, let alone exercised.  Someone ought to
>> build and test a copy with TEST_AND_SET deliberately removed from the
>> port.h file.
>
>MIght this not indicate that that code is, in fact, useless?  Designed for
>older OSs that didn't have appropriate support?

No, absolutely not!

If anyone want's to port to a new architecture they shouldn't have to learn
assembly language just to get started.  They should be able to make things
just work using semaphores, and then go back and add the TAS routines to
speed things up later.

Signature failed Preliminary Design Review.
Feasibility of a new signature is currently being evaluated.
h.b.hotz@jpl.nasa.gov, or hbhotz@oxy.edu