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 1wKuLT-001ObR-13 for pgsql-hackers@arkaria.postgresql.org; Thu, 07 May 2026 08:44:35 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wKuLS-002w4o-10 for pgsql-hackers@arkaria.postgresql.org; Thu, 07 May 2026 08:44:34 +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 1wKuK6-002td7-0J for pgsql-hackers@lists.postgresql.org; Thu, 07 May 2026 08:43:10 +0000 Received: from udcm-wwu2.uni-muenster.de ([128.176.118.28]) by makus.postgresql.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wKuK2-00000000cGL-3KJj for pgsql-hackers@postgresql.org; Thu, 07 May 2026 08:43:09 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uni-muenster.de; i=@uni-muenster.de; q=dns/txt; s=uniout; t=1778143387; x=1809679387; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=IeGDRjGS8QyH6rrXtlj57eLY3byQpsUdHAyIKp8iZmc=; b=LqCSPOalPcBY5S0LLk41++pB44/daT8yvL894MBhQI/I5uM4+sSvtVyA +GETdy9eD/MDQ5gDpuwgRTXZrTChR2dBOrLZ6KGvlzip7jVLXAl84jutR XjmF6L9q90Qe4voFXQ1plp7q4BtVwXnGto8fbzMr/dN9VbzHvPdXuRU7c ePMOH4rVm7YZ9IFflcw8/tq52pAi2wMPOuDNasZ0cVkEToseGwfOwPi6r ByVRBydymCNv4wJ2K7pMzfn671pdMcd2XkoXWfkKv+3iZZTb+ryX3fIq/ u5XGjTOFWBUHQ1ZVZ4OSHw7j1aXcr16KAS2tpuH68qaFbAlWlvzbcG1KM A==; X-CSE-ConnectionGUID: 4A0bSzQHT6ytZX++3eR5sQ== X-CSE-MsgGUID: NECUPWe3RYSlgJbo15NWYQ== X-IronPort-AV: E=Sophos;i="6.23,221,1770591600"; d="scan'208";a="393355943" Received: from secmail.uni-muenster.de ([128.176.118.4]) by UDCM-RELAY2.UNI-MUENSTER.DE with ESMTP; 07 May 2026 10:43:04 +0200 Received: from [192.168.178.49] (dynamic-093-133-053-119.93.133.pool.telefonica.de [93.133.53.119]) by SECMAIL.UNI-MUENSTER.DE (Postfix) with ESMTPSA id 4A61420ADF04; Thu, 7 May 2026 10:43:02 +0200 (CEST) Message-ID: <3aad711d-1eea-4989-b9e7-261eeffa5f5b@uni-muenster.de> Date: Thu, 7 May 2026 10:43:01 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Fix bug with accessing to temporary tables of other sessions To: Alexander Korotkov , Daniil Davydov <3danissimo@gmail.com> Cc: Michael Paquier , Soumya S Murali , Tom Lane , Stepan Neretin , PostgreSQL Hackers , Mohamed Ali , Nazneen Jafri , Shawn McCoy References: <239d181d-1415-49ee-ad57-b307f1a7ba66@uni-muenster.de> <0e666e40-d003-4c92-95cf-1a33a647401f@uni-muenster.de> Content-Language: de-DE, en-GB From: Jim Jones In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 07/05/2026 10:04, Alexander Korotkov wrote: > Thus, I don't see the reason why this shouldn't be committed and > backpatched to PG17 (first release containing b7b0f3f27241). Quick question: should we work on a separate patch for PG14-PG16? In these versions, the error message is raised depending on the temporary table's tuple count, as demonstrated in [1]: == session 1 == psql (14.20 (Debian 14.20-1.pgdg13+1)) Type "help" for help. postgres=# CREATE TEMPORARY TABLE t (id int); CREATE TABLE postgres=# \d pg_temp*.* Table "pg_temp_3.t" Column | Type | Collation | Nullable | Default --------+---------+-----------+----------+--------- id | integer | | | == session 2 == psql (14.20 (Debian 14.20-1.pgdg13+1)) Type "help" for help. postgres=# SELECT * FROM pg_temp_3.t; id ---- (0 rows) == session 1 == postgres=# INSERT INTO t VALUES (42); INSERT 0 1 == session 2 == postgres=# SELECT * FROM pg_temp_3.t; ERROR: cannot access temporary tables of other sessions Thanks! Best, Jim 1 - https://www.postgresql.org/message-id/800c75af-9bd0-48ac-b4bf-54cadf2bc723%40uni-muenster.de