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 1w5Kok-0038xo-0F for pgpool-hackers@arkaria.postgresql.org; Wed, 25 Mar 2026 09:46:26 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w5Koh-00DX4v-2H for pgpool-hackers@arkaria.postgresql.org; Wed, 25 Mar 2026 09:46:24 +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 1w5Koh-00DX4a-1l for pgpool-hackers@lists.postgresql.org; Wed, 25 Mar 2026 09:46:23 +0000 Received: from meldrar.postgresql.org ([2a02:c0:301:0:ffff::31]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1w5Kof-00000000whz-3bea for pgpool-hackers@lists.postgresql.org; Wed, 25 Mar 2026 09:46:23 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=postgresql.org; s=20171124; h=Content-Transfer-Encoding:Content-Type: Mime-Version:References:In-Reply-To:From:Subject:To:Message-Id:Date:Sender: Reply-To:Cc:Content-ID:Content-Description; bh=o0F9RAodjy5AfOuZK/5DzemRLJYcljut094SXsLOmnQ=; b=lrYzgK5/1lD3ej9VnD+jn/scs4 nMdOK6wO9rYqtAISkwQGZIjpuPTBluLB/6enu2uoaS+pB7eMQQzvAuHgQP/dcR1o2BMAXRZMpuQrl 2YchYvqWzbNHd86kgADFDo9sfKjXnoURcxElvVTC46fISkGt8saGe90HJN9dI13Io2zNpwnRU/dK0 QIxRnmiNo24S+3ohT3U7wdhuz3nuQ5u1hpD6tUJ+WSwl2zMbtIqSvvjsiZxlRud4opievDlpRNNyD 01SwLzVWTCJ0SEDjopWY1can7oA+vqBnUNTiv0KZWXfJdvohURFVL9VYWPn6bRdqGrck8QHMQB3io 30Zkux8A==; Received: from [2409:11:4120:300:76c3:4691:6:1cd7] (helo=localhost) by meldrar.postgresql.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w5Koc-005wZc-0R for pgpool-hackers@lists.postgresql.org; Wed, 25 Mar 2026 09:46:20 +0000 Date: Wed, 25 Mar 2026 18:46:11 +0900 (JST) Message-Id: <20260325.184611.1088077863621666688.ishii@postgresql.org> To: pgpool-hackers@lists.postgresql.org Subject: Re: pool_search_relcach does not consider session local cache case From: Tatsuo Ishii In-Reply-To: <20260320.115354.1808938375091443061.ishii@postgresql.org> References: <20260320.115354.1808938375091443061.ishii@postgresql.org> X-Mailer: Mew version 6.8 on Emacs 29.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Host-Lookup-Failed: Reverse DNS lookup failed for 2409:11:4120:300:76c3:4691:6:1cd7 (failed) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk > While looking into https://github.com/pgpool/pgpool2/issues/154 > I found a bug with pool_search_relcach. > > pool_search_relcache does not consider the session local cache case > such as temp table search. It creates the search result in shared > relation cache even if the relation cache is session local. As a > result subsequent query against the session local cache is returned > from the shared relation cache. This could cause wrong > result. Example: > > create table t1(i int); > select * from t1; -- info "t1 is not a temp table" is registered in shared cache > drop table t1; > create temp table t1(i int); > select * from t1; -- shared cache tells that t1 is not temp table and it could be load balanced, > -- it could access non existent table from standby nodes. > > Fix is, to not register a temp table to shared relation cache if it's > a session local cache. > > Patch attached. Patch pushed to down to v4.4. A test is also added down to v4.5 (v4.4's test script is not suitable to apply the same patch as master - v4.5). Regards, -- Tatsuo Ishii SRA OSS K.K. English: http://www.sraoss.co.jp/index_en/ Japanese:http://www.sraoss.co.jp