Date: Thu, 19 Mar 2026 15:37:04 +0900 (JST)
Message-Id: <20260319.153704.1746090050786287316.ishii@postgresql.org>
To: pgpool-hackers@lists.postgresql.org
Subject: Re: Lock release leak in pool_search_relcache
From: Tatsuo Ishii <ishii@postgresql.org>
In-Reply-To: <20260317.182615.1046517700474336117.ishii@postgresql.org>
References: <20260317.182615.1046517700474336117.ishii@postgresql.org>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/20260319.153704.1746090050786287316.ishii%40postgresql.org>
Precedence: bulk

> While looking into src/utils/pool_relcache.c for other reasons, I
> noticed pool_search_relcache does not release lock in a certain code
> path.  When the local relation cache does not hit, it searches the
> shared relation cache if enable_shared_relcache is on. If the lock for
> query cache has been already held (thus the variable "locked" is set
> to true), it acquires a shared lock, then releases it and acquires an
> exclusive lock to call pool_catalog_commit_cache. Since in this code
> path variable "locked" is set to true, subsequent code:
> 
> 	if (pool_config->enable_shared_relcache && !locked)
> 	{
> 		pool_shmem_unlock();
> 		POOL_SETMASK(&oldmask);
> 	}
> 
> does not reach inside the if statement -- lock is not released. I
> think to fix this, the following code requires "locked = false;"
> 
> 			pool_shmem_unlock();
> 			pool_shmem_lock(POOL_MEMQ_EXCLUSIVE_LOCK);
> 			pool_catalog_commit_cache(backend, query, query_cache_data, query_cache_len);
> 
> Attached patch does this. Plus following changes are made in the patch:
> 
> - the variable name "locked" is confusing. To clarify the role of the
>   variable, its name is changed to "locked_by_others".
> 
> - Fix per_node_statement_log is called even though actual query is
>   not sent to backend.

Pushed down to v4.4 stable.

Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp