Return-Path: owner-postman Received: from faerie.CS.Berkeley.EDU (faerie.CS.Berkeley.EDU [128.32.37.53]) by nobozo.CS.Berkeley.EDU (8.6.10/8.6.3) with ESMTP id VAA17658 for ; Wed, 8 Mar 1995 21:47:50 -0800 Received: from localhost.Berkeley.EDU (localhost.Berkeley.EDU [127.0.0.1]) by faerie.CS.Berkeley.EDU (8.6.10/8.6.3) with SMTP id VAA19140; Wed, 8 Mar 1995 21:47:45 -0800 Message-Id: <199503090547.VAA19140@faerie.CS.Berkeley.EDU> X-Authentication-Warning: faerie.CS.Berkeley.EDU: Host localhost.Berkeley.EDU didn't use HELO protocol From: aoki@CS.Berkeley.EDU (Paul M. Aoki) To: "Andrew K. Yu" Cc: sunita@postgres.Berkeley.EDU (Sunita Sarawagi), postgres-arch@postgres.Berkeley.EDU Subject: Re: sunita's bufmgr bug Reply-To: aoki@CS.Berkeley.EDU (Paul M. Aoki) In-reply-to: Your message of Wed, 8 Mar 1995 15:33:28 -0800 <199503082333.PAA00124@eden.CS.Berkeley.EDU> Date: Wed, 08 Mar 95 21:47:45 -0800 Sender: aoki@postgres.Berkeley.EDU X-Mts: smtp "Andrew K. Yu" writes: > hey Paul, we seem to have found the bug (that you introduce last > July while you're optimizing the bufmgr). look carefully at the rcs history. the last two revisions strictly increased the amount of code covered by mutexes. for example, the tag operations in BufferReplace weren't mutexed at all before the last revision. this sort of worked on suns but didn't work so well on alphas because of their memory consistency model. the business of giving up the mutex in BufferAlloc before calling BufferReplace has *always* been there. look at any previous revision. the OPTIMIZE_SINGLE business is something that i added that *avoids* giving up the mutex during the i/o when defined (evidently the more correct behavior anyway, oh well) because semop(3) is so expensive under ultrix (no TASlocks). without -DOPTIMIZE_SINGLE, BufferAlloc has the same behavior that was there for the last 83 revisions. -- Paul M. Aoki | University of California at Berkeley aoki@CS.Berkeley.EDU | Dept. of EECS, Computer Science Division (#1776) | Berkeley, CA 94720-1776