Received: from maia.hub.org (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id D66F462DBD5 for ; Mon, 8 Feb 2010 21:19:34 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 17850-01-6 for ; Tue, 9 Feb 2010 01:18:50 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from spinlock.commandprompt.com (host-215.commandprompt.net [207.173.203.215]) by mail.postgresql.org (Postfix) with ESMTP id EB129634E9D for ; Mon, 8 Feb 2010 21:18:13 -0400 (AST) Received: from localhost (localhost [127.0.0.1]) by spinlock.commandprompt.com (Postfix) with ESMTP id B9993348040; Mon, 8 Feb 2010 17:18:10 -0800 (PST) Received: from spinlock.commandprompt.com ([127.0.0.1]) by localhost (spinlock.commandprompt.com.commandprompt.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id enR7-FXx6FMd; Mon, 8 Feb 2010 17:18:10 -0800 (PST) Received: from perhan.alvh.no-ip.org (190-95-31-230.bk17-dsl.surnet.cl [190.95.31.230]) by spinlock.commandprompt.com (Postfix) with ESMTPSA id 55025348036; Mon, 8 Feb 2010 17:18:10 -0800 (PST) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 312936E810; Mon, 8 Feb 2010 22:18:08 -0300 (CLST) Date: Mon, 8 Feb 2010 22:18:08 -0300 From: Alvaro Herrera To: Tom Lane Cc: Heikki Linnakangas , pgsql-hackers@postgreSQL.org Subject: Re: Order of operations in lazy_vacuum_rel Message-ID: <20100209011808.GA4113@alvh.no-ip.org> References: <13481.1265650179@sss.pgh.pa.us> <20100208173855.GN4113@alvh.no-ip.org> <13824.1265651227@sss.pgh.pa.us> <20100208191917.GO4113@alvh.no-ip.org> <2770.1265675743@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2770.1265675743@sss.pgh.pa.us> User-Agent: Mutt/1.5.20 (2009-06-14) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.544 tagged_above=-10 required=5 tests=AWL=0.055, BAYES_00=-2.599 X-Spam-Level: X-Archive-Number: 201002/572 X-Sequence-Number: 156915 Tom Lane wrote: > Actually, after thinking about this some more, I realize that this code > has got a significantly bigger problem than just whether it will respond > to CANCEL promptly. If we truncate the table, and then get an error > sometime before commit, the relcache inval message will not be sent, > leaving other backends at significant risk of strange errors due to > having rd_targblock pointing somewhere past the end of the table. > So we should reorder these operations just to reduce the risk window, > and I've done so. Err, that problem was exactly why I added the interrupt holdoff in there, so if you've got a better/more invasive solution, it's very welcome. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support