Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w9ZzD-001YdD-1u for pgsql-bugs@arkaria.postgresql.org; Mon, 06 Apr 2026 02:46:47 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w9ZzC-0067HX-0W for pgsql-bugs@arkaria.postgresql.org; Mon, 06 Apr 2026 02:46:46 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w9ZzB-0067HP-2y for pgsql-bugs@lists.postgresql.org; Mon, 06 Apr 2026 02:46:46 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1w9Zz9-00000000mo2-2GAG for pgsql-bugs@lists.postgresql.org; Mon, 06 Apr 2026 02:46:45 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 6362keIl1196656; Sun, 5 Apr 2026 22:46:40 -0400 From: Tom Lane To: Dmitriy Kuzmin cc: "David G. Johnston" , "pgsql-bugs@lists.postgresql.org" Subject: Re: BUG #19437: temp_tablespaces doesn't work inside a cursor? In-reply-to: References: <19437-0a65fb52d0f13a0d@postgresql.org> <233968.1774445501@sss.pgh.pa.us> Comments: In-reply-to Dmitriy Kuzmin message dated "Mon, 06 Apr 2026 11:16:19 +1000" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1196654.1775443600.1@sss.pgh.pa.us> Date: Sun, 05 Apr 2026 22:46:40 -0400 Message-ID: <1196655.1775443600@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Dmitriy Kuzmin writes: > Any news on these issues? I don't see any bug here. You're expecting the ALTER SYSTEM SET change to propagate instantaneously after pg_reload_conf(), but it doesn't. I cannot replicate your claim that the setting changes once it has been received, either. The fact that DECLARE CURSOR isn't using a temp tablespace is intentional, according to the comments in OpenTemporaryFile: * If some temp tablespace(s) have been given to us, try to use the next * one. If a given tablespace can't be found, we silently fall back to * the database's default tablespace. * * BUT: if the temp file is slated to outlive the current transaction, * force it into the database's default tablespace, so that it will not * pose a threat to possible tablespace drop attempts. The reason it thinks the temp file may need to outlive the current transaction is that we're putting the FETCH results into the current Portal's holdStore, which is specifically intended to possibly outlive the transaction. Since you didn't say WITH HOLD in the DECLARE CURSOR, maybe there's an optimization possibility there. But I'm not sure --- I think the details of the wire protocol may foreclose throwing the Portal's results away until it's explicitly closed. I didn't go looking to see how well these details are documented. regards, tom lane