Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gXriM-0000n2-Un for pgsql-hackers@arkaria.postgresql.org; Fri, 14 Dec 2018 17:57:31 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gXriL-0002uJ-Bg for pgsql-hackers@arkaria.postgresql.org; Fri, 14 Dec 2018 17:57:29 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gXriL-0002tT-1N for pgsql-hackers@lists.postgresql.org; Fri, 14 Dec 2018 17:57:29 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gXriI-0000pQ-GD for pgsql-hackers@lists.postgresql.org; Fri, 14 Dec 2018 17:57:27 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id wBEHvNek008546; Fri, 14 Dec 2018 12:57:23 -0500 From: Tom Lane To: Robert Haas cc: Alvaro Herrera , PostgreSQL Hackers Subject: Re: removal of dangling temp tables In-reply-to: References: <20181214162843.37g6h3txto43akrb@alvherre.pgsql> Comments: In-reply-to Robert Haas message dated "Fri, 14 Dec 2018 11:48:45 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <8544.1544810243.1@sss.pgh.pa.us> Date: Fri, 14 Dec 2018 12:57:23 -0500 Message-ID: <8545.1544810243@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Robert Haas writes: > On Fri, Dec 14, 2018 at 11:29 AM Alvaro Herrera > wrote: >> I think the best way to fix this is to call RemoveTempRelations() >> unconditionally at session start (without doing the rest of the temp >> table setup, just the removal.) > That would certainly simplify things. I think I thought about that as > far back as a734fd5d1c309cc553b7c8c79fba96218af090f7 but it seemed > like a significant behavior change and I wasn't sure that everyone > would like it. In particular, it adds overhead to backend startup > that, in the case of a large temp schema, could be fairly long. > Nevertheless, I tentatively think that a change like this is a good > idea. I wouldn't back-patch it, though. I seem to recall discussions about having crash recovery go around and clean out temp tables. That seems like a better plan than penalizing every session start with this. regards, tom lane