Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 81C9F64FD15 for ; Wed, 29 Oct 2008 10:17:35 -0300 (ADT) Received: from postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 93682-06 for ; Wed, 29 Oct 2008 10:17:20 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by postgresql.org (Postfix) with ESMTP id 295BD64FD76 for ; Wed, 29 Oct 2008 10:17:19 -0300 (ADT) Received: by fg-out-1718.google.com with SMTP id 16so30652fgg.23 for ; Wed, 29 Oct 2008 06:17:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=cOgSAhpat9+ex+qZwJ4t9fq+vKZHQvAoSeeDhXSvKmw=; b=Kj/GgsZfwi3daEO5Hag/zagTErXM5m3TU4C8Vwq4+ueF4DEoi8yReZpOPFTgSzITQi rrDMb0FX8rTF6HlLmSMDyxZpsehx4h9ce7hltYjqfpQ0G8y23OM0c+yEw4f8xSnJ4FaW y7RK4JilBqCaDl2CDEgKqjQITPjYw7yWVxS10= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=xAoSJfeSQAWWqg2W2IizC3BV2EKM+Yrp8aEzlnKpjMySFVqwwzDqu6l3vDGXWzpF92 0UNCQCtdUyFDhVMe3AY1iwXCiaA4/u/pIKnOX6zkbhkk1GVmg2PhPCUd2oHLvcQq8/Ks /4Ychn/UwzUZkdzn9gvIk87tFp4AXiUzPXvZo= Received: by 10.187.211.13 with SMTP id n13mr841414faq.39.1225286238194; Wed, 29 Oct 2008 06:17:18 -0700 (PDT) Received: by 10.187.187.18 with HTTP; Wed, 29 Oct 2008 06:17:18 -0700 (PDT) Message-ID: <603c8f070810290617rcdc4da4yc2cf88deae4b5ae3@mail.gmail.com> Date: Wed, 29 Oct 2008 09:17:18 -0400 From: "Robert Haas" To: "Heikki Linnakangas" Subject: Re: Updating FSM on recovery Cc: "Tom Lane" , PostgreSQL-development In-Reply-To: <49085327.5010608@enterprisedb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <49072021.7010801@enterprisedb.com> <24334.1225205478@sss.pgh.pa.us> <49074779.2080309@enterprisedb.com> <9672.1225215390@sss.pgh.pa.us> <49085327.5010608@enterprisedb.com> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200810/1489 X-Sequence-Number: 126506 > Buffer ReadBuffer(Relation reln, BlockNumber blockNum); > Buffer ReadBufferExt(Relation reln, ForkNumber forkNum, BlockNumber > blockNum, BufferAccessStrategy strategy, ReadBufferMode mode); > Buffer ReadBufferWithoutRelcache(RelFileNode rnode, bool isTemp, ForkNumber > forkNum, BlockNumber blockNum, ReadBufferMode mode); > > Thoughts? I'm not sure why we would abbreviate Extended to Ext when nothing else in here is abbreviated. Seems needlessly inconsistent. We may also want to rethink our approach to BufferAccessStrategy a bit. Right now, we don't admit that GetBufferAccessStrategy(BAS_NORMAL) just returns a NULL pointer - we expect the caller to get that strategy and later call FreeBufferAccessStrategy it just as if it were a real object. Particularly in light of this API change, I think we should just give up on that. Otherwise, a caller that wants to specify a fork number or ReadBufferMode has to get and free an access strategy that doesn't amount to anything. Perhaps it would be sufficient to do this: #define NormalBufferAccessStrategy NULL That way, it would be easy to grep for any place where we used this to get around a useless pair of get/free calls if we ever need to go back and make a normal buffer access strategy into a real object. ...Robert