Received: from maia.hub.org (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 90CA0632FED for ; Sun, 25 Apr 2010 12:35:30 -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 39366-02 for ; Sun, 25 Apr 2010 15:35:10 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-iw0-f202.google.com (mail-iw0-f202.google.com [209.85.223.202]) by mail.postgresql.org (Postfix) with ESMTP id C60BA632F70 for ; Sun, 25 Apr 2010 12:35:19 -0300 (ADT) Received: by iwn40 with SMTP id 40so2505123iwn.1 for ; Sun, 25 Apr 2010 08:35:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=szhTvKtqCr6ma1MciQ7aWFA8BCm0/u0+tQFOkiJSQgE=; b=xHf4VycICWuBqhV8CNI04gFO78PHoq8gWKCRSZFVUQhRsB0LxtTekCArJYWSunqiJN 4KsNuah1gbHmnCgw6+0KbfLke4/VwRv2rqcFuexKIOcDzFP3oWIGr2Xu6BsETydHRM/b x3/IEEJJdy3n1YoIDcTxVFQo87oXcQlebLURM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=RMl63TNFVMUmhhqloG+PjhfeiLUKxq58TBHLDQBBB2WrRYyfgTsw238J10ORf+VVTV 1eb7tPtCf+Hp/e9ppWoAq6gJDXmmP7aQ3oMFVwXNUpcao0Lcw+XbXcc39TDzAPF9N8oo dwGTk0Abbpo5euyfJ61UfplMQPc56+gLsHHP8= MIME-Version: 1.0 Received: by 10.231.166.211 with SMTP id n19mr938079iby.60.1272209718762; Sun, 25 Apr 2010 08:35:18 -0700 (PDT) Received: by 10.231.12.129 with HTTP; Sun, 25 Apr 2010 08:35:18 -0700 (PDT) In-Reply-To: <1272200241.4161.1670.camel@ebony> References: <1272148142.4161.1598.camel@ebony> <1272181795.4161.1604.camel@ebony> <1272200241.4161.1670.camel@ebony> Date: Sun, 25 Apr 2010 11:35:18 -0400 Message-ID: Subject: Re: global temporary tables From: Robert Haas To: Simon Riggs Cc: pgsql-hackers@postgresql.org Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.07 tagged_above=-10 required=5 tests=AWL=-0.170, BAYES_00=-1.9 X-Spam-Level: X-Archive-Number: 201004/1156 X-Sequence-Number: 161268 On Sun, Apr 25, 2010 at 8:57 AM, Simon Riggs wrote: >> I don't think that quite works, because the standby might assign a >> relfilenode number for a global temp table and then the master might >> subsequently assign the same relfilenode number to a regular table. >> We might be able to make that not matter, but it's far from obvious to >> me that there are no gotchas there... > > That sounds fairly simple to solve. > > All I am saying is please include "working on the standby" as part of > your requirement. Well, I think I already basically stated my position on this, but let me try to be more clear. I'm not promising to work on any portion of this project AT ALL or to have it done at any particular time. I am specifically not promising to do the extra work required to make it work with Hot Standby, although I am also not saying that I won't. Nobody has offered to fund any portion of this work, so there are no guarantees, full stop. Even if you could successfully convince a critical mass of people on this list that the work should not be committed without adding support for temp tables in Hot Standby mode, the most likely result of that would be that I would give up and not pursue this at all, rather than that I would agree to do that in addition to solving all the problems already discussed. And I don't think you can even get that far, because I don't think too many people here are going to say that we shouldn't add global temporary tables unless we can also make them work with Hot Standby. In all honesty, I would think that you would be happy about my possibly implementing a flavor of temporary tables that would be substantially more feasible to make work with Hot Standby than the kind we have now, rather than (as you seem to be) complaining that I'm not solving the entire problem. ...Robert