Received: from localhost (maia-1.hub.org [200.46.204.191]) by postgresql.org (Postfix) with ESMTP id 7AD1A9FB8A2 for ; Mon, 5 Mar 2007 15:37:07 -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 80317-05 for ; Mon, 5 Mar 2007 15:36:58 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from rivendell.solution-x.com (rivendell.solution-x.com [213.147.174.20]) by postgresql.org (Postfix) with ESMTP id E82899FB89D for ; Mon, 5 Mar 2007 15:36:57 -0400 (AST) Received: (qmail 9472 invoked from network); 5 Mar 2007 19:36:53 -0000 Received: from qmail by qscan (mail filter); 5 Mar 2007 19:36:53 +0000 Received: from unknown (HELO [10.100.5.180]) (fgp@[10.100.5.180]) (envelope-sender ) by rivendell.solution-x.com (qmail-ldap-1.03) with SMTP for ; 5 Mar 2007 19:36:53 -0000 Message-ID: <45EC7274.20502@phlo.org> Date: Mon, 05 Mar 2007 20:41:40 +0100 From: "Florian G. Pflug" User-Agent: Thunderbird 1.5.0.9 (X11/20070103) MIME-Version: 1.0 To: Heikki Linnakangas CC: Tom Lane , ITAGAKI Takahiro , pgsql-hackers@postgresql.org, pgsql-patches@postgresql.org Subject: Re: [PATCHES] Aggressive freezing in lazy-vacuum References: <20070227141958.638D.ITAGAKI.TAKAHIRO@oss.ntt.co.jp> <20070227170613.GK29041@nasby.net> <20070305182401.C4BC.ITAGAKI.TAKAHIRO@oss.ntt.co.jp> <18982.1173110551@sss.pgh.pa.us> <45EC6F02.1050306@phlo.org> <45EC6FB8.8090603@enterprisedb.com> In-Reply-To: <45EC6FB8.8090603@enterprisedb.com> 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=0.058 tagged_above=0 required=5 tests=AWL, BAYES_50, UNPARSEABLE_RELAY X-Spam-Level: X-Archive-Number: 200703/306 X-Sequence-Number: 99790 Heikki Linnakangas wrote: > Florian G. Pflug wrote: >> There could be a GUC vacuum_freeze_limit, and the actual FreezeLimit >> would be calculated as >> GetOldestXmin() - vacuum_freeze_limit > > We already have that. It's called vacuum_freeze_min_age, and the default > is 100 million transactions. > > IIRC we added it late in the 8.2 release cycle when we changed the clog > truncation point to depend on freeze limit. Ok, that explains why I didn't find it when I checked the source - I checked the 8.1 sources by accident ;-) Anyway, thanks for pointing that out ;-) greetings, Florian Pflug