Received: from maia.hub.org (maia-1.hub.org [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 601C7633DAA for ; Mon, 26 Apr 2010 17:19:03 -0300 (ADT) 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 08271-03 for ; Mon, 26 Apr 2010 20:18:48 +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 A7C0B633D8E for ; Mon, 26 Apr 2010 17:18:52 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by spinlock.commandprompt.com (Postfix) with ESMTP id 3D53834803A; Mon, 26 Apr 2010 13:18:51 -0700 (PDT) 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 Id2uwEmW9GB2; Mon, 26 Apr 2010 13:18:51 -0700 (PDT) Received: from perhan.alvh.no-ip.org (unknown [190.95.9.187]) by spinlock.commandprompt.com (Postfix) with ESMTPSA id AAC39348035; Mon, 26 Apr 2010 13:18:50 -0700 (PDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 47CDE6E48C; Mon, 26 Apr 2010 16:18:47 -0400 (CLT) Date: Mon, 26 Apr 2010 16:18:47 -0400 From: Alvaro Herrera To: Tom Lane Cc: Robert Haas , Greg Sabino Mullane , pgsql-hackers@postgresql.org Subject: Re: global temporary tables Message-ID: <20100426201847.GF3963@alvh.no-ip.org> References: <7796.1272125493@sss.pgh.pa.us> <9452.1272130726@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9452.1272130726@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.164 tagged_above=-10 required=5 tests=AWL=-0.264, BAYES_00=-1.9 X-Spam-Level: X-Archive-Number: 201004/1227 X-Sequence-Number: 161339 Tom Lane escribió: > [ forgot to respond to this part ] > > Robert Haas writes: > > ... I don't see the problem with DROP. > > Under the proposed design, it's approximately equivalent to dropping a > > table that someone else has truncated. You just wait for the > > necessary lock and then do it. > > And do *what*? You can remove the catalog entries, but how are you > going to make the physical storage of other backends' versions go away? > (To say nothing of making them flush their local buffers for it.) Maybe we could add a sinval message to that effect. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support