Date: Fri, 19 Jun 2026 11:10:37 +0900 (JST)
Message-Id: <20260619.111037.159094338431818955.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: 
 <CACeKOO02V7_SBpCUJWG7yS-ABNEXzAAU-vb+JrY=rD8yBiiy0g@mail.gmail.com>
References: 
 <CACeKOO1Gg6V4+eE8F+yCXRDwa_d5KAwk7OV+X-Z+tEMEstLMtg@mail.gmail.com>
	<20260604.185936.1758441592589268635.ishii@postgresql.org>
	<CACeKOO02V7_SBpCUJWG7yS-ABNEXzAAU-vb+JrY=rD8yBiiy0g@mail.gmail.com>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/20260619.111037.159094338431818955.ishii%40postgresql.org>
Precedence: bulk

> understood. we'll wait patiently or try master.
> 
> thanks!

While reviewing
v5-0002-Feature-load-balancing-control-by-table-tracking.patch, I
noticed following code:

 static void
 dml_adaptive(Node *node, char *query)
 {
:
:
+				/*
+				 * For dml_adaptive_global: on COMMIT, flush the accumulated
+				 * table writes to shared memory.  On ROLLBACK, skip -- the
+				 * writes never committed so no stale-read risk exists.  This
+				 * prevents polluting the table map with rolled-back
+				 * transactions.
+				 */
+				int			dlbow =
+				pool_config->disable_load_balance_on_write;
+				List	   *wlist =
+				session_context->transaction_temp_write_list;
+
+				if (dlbow == DLBOW_DML_ADAPTIVE_GLOBAL &&
+					is_commit_query(node) &&
+					wlist != NIL)
+				{
+					ListCell   *cell;
+					int			dboid;
+
+					dboid =
+						pool_track_table_mutation_get_database_oid();
+					if (dboid > 0)
+					{
+						foreach(cell, wlist)
+						{
+							char	   *tname;
+							int			toid;
+
+							tname = (char *) lfirst(cell);
+							toid =
+								pool_table_name_to_oid(tname);
+
+							if (toid > 0)
+								pool_track_table_mutation_mark_table_written(
+																			 toid, dboid);
+						}

The code path is executed before the commit command is sent to primary
PostgreSQL. I wonder what will happen if the commit command failed?
Example:

CREATE TEMP TABLE t1(i int PRIMARY KEY DEFERRABLE INITIALLY DEFERRED);
CREATE TABLE
INSERT INTO t1 VALUES(1);
INSERT 0 1
BEGIN;
BEGIN
INSERT INTO t1 VALUES(1);
INSERT 0 1
INSERT INTO t1 VALUES(2);
INSERT 0 1
COMMIT;
psql:deferable.sql:6: ERROR:  duplicate key value violates unique constraint "t1_pkey"
DETAIL:  Key (i)=(1) already exists.

As you can see, the COMMIT command failed and the effect of INSERT
commands vanished too. However the code invalidates the data on the
shared memory by pool_track_table_mutation_mark_table_written() when
it should not be called?

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