Received: from localhost (maia-4.hub.org [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 839569FB7E1 for ; Tue, 27 Feb 2007 12:58:39 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-new, port 10024) with ESMTP id 93079-06 for ; Tue, 27 Feb 2007 12:58:34 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from noel.decibel.org (noel.decibel.org [67.100.216.10]) by postgresql.org (Postfix) with ESMTP id 05D549FB35A for ; Tue, 27 Feb 2007 12:58:33 -0400 (AST) Received: by noel.decibel.org (Postfix, from userid 1001) id AE7F356453; Tue, 27 Feb 2007 10:58:30 -0600 (CST) Received: (hashcash-sendmail, from uid 1001); Tue, 27 Feb 2007 10:58:26 -0600 Date: Tue, 27 Feb 2007 10:58:26 -0600 From: "Jim C. Nasby" To: Tom Lane Cc: ITAGAKI Takahiro , pgsql-hackers@postgresql.org Subject: Re: Dead Space Map version 2 Message-ID: <20070227165825.GJ29041@nasby.net> References: <20070227113655.6381.ITAGAKI.TAKAHIRO@oss.ntt.co.jp> <20070227051144.GK29041@nasby.net> <12631.1172555721@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <12631.1172555721@sss.pgh.pa.us> X-Operating-System: FreeBSD 6.1-RELEASE-p10 amd64 X-Distributed: Join the Effort! http://www.distributed.net User-Agent: Mutt/1.5.13 (2006-08-11) X-Hashcash: 1:20:070227:tgl@sss.pgh.pa.us::38L/264LUS3KE64y:00000000000000000000 0000000000000000000000002Rdo X-Hashcash: 1:20:070227:itagaki.takahiro@oss.ntt.co.jp::il+EYMS2nCPgaUVV:0000000 0000000000000000000000004wtp X-Hashcash: 1:20:070227:pgsql-hackers@postgresql.org::BZB3WX4v3sgUYy1h:000000000 000000000000000000000000I6bx X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200702/1712 X-Sequence-Number: 99265 On Tue, Feb 27, 2007 at 12:55:21AM -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. My thought would be to revert to a FSM that has pages marked as free that no longer are. Could be done by writing the FSM out every time we add pages to it. After an unclean restart backends would be getting pages from the FSM that didn't have free space, in which case they'd need to yank that page out of the FSM and request a new one. Granted, this means extra IO until the FSM gets back to a realistic state, but I suspect that's better than bloating tables out until the next vacuum. And it's ultimately less IO than re-vacuuming every table to rebuild the FSM. -- Jim Nasby jim@nasby.net EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)