Date: Thu, 21 May 2026 18:50:44 +0900 (JST)
Message-Id: <20260521.185044.504532841722447976.ishii@postgresql.org>
To: nadav@tailorbrands.com
Cc: pgpool-hackers@lists.postgresql.org
Subject: Re: Proposal: Recent mutated table tracking in memory
From: Tatsuo Ishii <ishii@postgresql.org>
In-Reply-To: 
 <CACeKOO2eUrfo_UDMFSEd=2y8zj8y93m38EzRCpg1HuizYBf3wA@mail.gmail.com>
References: <20260518.191105.282754674107940178.ishii@postgresql.org>
	<20260520.132810.1024114140609315185.ishii@postgresql.org>
	<CACeKOO2eUrfo_UDMFSEd=2y8zj8y93m38EzRCpg1HuizYBf3wA@mail.gmail.com>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/20260521.185044.504532841722447976.ishii%40postgresql.org>
Precedence: bulk

Hi Nadav,

> Hi Tatsuo,
> 
> Thanks for checking the V3, sorry for missing the test issue.
> 
> I reproduced the timeout locally. Found and fixed the root cause.
> 
> Root cause
> ----------
> 
> In CommandComplete.c, the autocommit write-tracking code was
> gated only on session_context->is_in_transaction, not on the
> cluster mode.

I think you are talking about the logic to judge whether we are in an
explicite transaction or not here. Current dml_adaptive checks
supplied query is a transaction starting command like BEGIN. IMO this
is fundamentaly wrong because the command may fail by various reasons.
The correct way is checking transaction state by using TSTATE
macro. Note that the macro can only be used at leat one ready for
query response returned from backend (simple query protocol case), or
command complete response is returned from backend (extended query
protocol case).

> In native replication and snapshot isolation modes,
> dml_adaptive() is never called (it lives inside
> where_to_send_main_replica), so is_in_transaction is never set
> to true even inside an explicit BEGIN/COMMIT block.  That meant
> every DML in those modes was treated as autocommit by the
> write-tracking code, triggering
> pool_track_table_mutation_get_database_oid() ― which does a
> relcache do_query ― while a transaction was actually in flight
> on the backend connection.  The do_query conflicts with the
> in-flight transaction and hangs the session.

Assuming "a transaction was actually in flight" means a transaction
was open (explicit transaction), not really. do_query can be called
inside or outside of an explicit transaction.

Anyway, I found dml_adaptive is completely broken (it brings wrong
results if query cache enabled). Unless there are users for the
feature, maybe we should remove dml_adaptive entirely?

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