Received: from localhost (maia-1.hub.org [200.46.204.191]) by postgresql.org (Postfix) with ESMTP id 5144A9FB9F5 for ; Tue, 27 Feb 2007 04:19:45 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.191]) (amavisd-new, port 10024) with ESMTP id 50483-04-2 for ; Tue, 27 Feb 2007 04:19:41 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from mail01.enterprisedb.com (mail01.enterprisedb.com [63.246.7.168]) by postgresql.org (Postfix) with ESMTP id 50D439FB9B0 for ; Tue, 27 Feb 2007 04:19:37 -0400 (AST) thread-index: AcdaSAuHuBJjPrNiSVmGrSoT7y+5OA== Received: from [192.168.0.22] ([81.6.226.224]) by mail01.enterprisedb.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Feb 2007 03:19:45 -0500 Content-Class: urn:content-classes:message Subject: Re: Dead Space Map version 2 Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 From: "Simon Riggs" To: "Tom Lane" Cc: "Jim C. Nasby" , "ITAGAKI Takahiro" , In-Reply-To: <12631.1172555721@sss.pgh.pa.us> References: <20070227113655.6381.ITAGAKI.TAKAHIRO@oss.ntt.co.jp> <20070227051144.GK29041@nasby.net> <12631.1172555721@sss.pgh.pa.us> Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 27 Feb 2007 08:16:54 +0000 Message-ID: <1172564214.3760.547.camel@silverbirch.site> MIME-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Feb 2007 08:19:46.0078 (UTC) FILETIME=[0A5423E0:01C75A48] X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.068 tagged_above=0 required=5 tests=AWL, BAYES_50 X-Spam-Level: X-Archive-Number: 200702/1675 X-Sequence-Number: 99228 On Tue, 2007-02-27 at 00:55 -0500, Tom Lane wrote: > "Jim C. Nasby" writes: > > Yes, DSM would make FSM recovery more important, but I thought it was > > recoverable now? Or is that only on a clean shutdown? > > Currently we throw away FSM during any non-clean restart. This is > probably overkill but I'm quite unclear what would be a safe > alternative. > > > I suspect we don't need perfect recoverability... > > The main problem with the levels proposed by Takahiro-san is that any > transition from FROZEN to not-FROZEN *must* be exactly recovered, > because vacuum will never visit an allegedly frozen page at all. This > appears to require WAL-logging DSM state changes, which is a pretty > serious performance hit. I'd be happier if the DSM content could be > treated as just a hint. I think that means not trusting it for whether > a page is frozen to the extent of not needing vacuum even for > wraparound. Agreed. > So I'm inclined to propose that there be only two states > (hence only one DSM bit per page): page needs vacuum for space recovery, > or not. Vacuum for XID wraparound would have to hit every page > regardless. I'm inclined to think: this close to deadline it would be more robust to go with the simpler option. So, agreed to the one bit per page. We can revisit the 2 bits/page idea easily for later releases. If the DSM is non-transactional, upgrading to a new format in the future should be very easy. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com