Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id 5A671B5DCF4 for ; Mon, 3 Oct 2011 04:24:50 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 04470-01-8 for ; Mon, 3 Oct 2011 07:24:43 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0-rc2 Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by mail.postgresql.org (Postfix) with ESMTP id A8061B5F5D2 for ; Mon, 3 Oct 2011 04:21:31 -0300 (ADT) Received: from mail-ey0-f179.google.com ([209.85.215.179]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP; Mon, 03 Oct 2011 00:21:32 PDT Received: by eyh5 with SMTP id 5so2643991eyh.38 for ; Mon, 03 Oct 2011 00:21:29 -0700 (PDT) Received: by 10.223.56.67 with SMTP id x3mr17903393fag.64.1317626489528; Mon, 03 Oct 2011 00:21:29 -0700 (PDT) Received: from [192.168.1.183] (dsl-hkibrasgw2-ff7ac300-240.dhcp.inet.fi. [88.195.122.240]) by mx.google.com with ESMTPS id o16sm20082299fag.21.2011.10.03.00.21.27 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 03 Oct 2011 00:21:28 -0700 (PDT) Message-ID: <4E896276.7020209@enterprisedb.com> Date: Mon, 03 Oct 2011 10:21:26 +0300 From: Heikki Linnakangas User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; fi-FI; rv:1.9.2.21) Gecko/20110831 Icedove/3.1.13 MIME-Version: 1.0 To: Fujii Masao CC: Florian Pflug , Tom Lane , Simon Riggs , PostgreSQL-development Subject: Re: bug of recovery? References: <889.1317069556@sss.pgh.pa.us> <4E816650.80607@enterprisedb.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-5 required=5 tests=BAYES_00=-1.9 X-Spam-Level: X-Archive-Number: 201110/53 X-Sequence-Number: 195859 On 29.09.2011 14:31, Fujii Masao wrote: > On Tue, Sep 27, 2011 at 8:06 PM, Florian Pflug wrote: >> Actually, why don't we use that machinery to implement this? There's currently no rm_safe_restartpoint callback for RM_XLOG_ID, so we'd just need to create one that checks whether invalid_page_tab is empty. > > Okay, the attached patch prevents the creation of restartpoints by using > rm_safe_restartpoint callback if we've not reached a consistent state yet > and the invalid-page table is not empty. But the invalid-page table is not > tied to the specific resource manager, so using rm_safe_restartpoint for > that seems to slightly odd. Is this OK? I don't think this should use the rm_safe_restartpoint machinery. As you said, it's not tied to any specific resource manager. And I've actually been thinking that we will get rid of rm_safe_restartpoint altogether in the future. The two things that still use it are the b-tree and gin, and I'd like to change both of those to not require any post-recovery cleanup step to finish multi-page operations, similar to what I did with GiST in 9.1. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com