public inbox for [email protected]  

help / color / mirror / Atom feed

From: Tatsuo Ishii <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: Proposal: Recent mutated table tracking in memory
Date: Fri, 19 Jun 2026 11:10:37 +0900 (JST)
Message-ID: <[email protected]> (raw)
In-Reply-To: <CACeKOO02V7_SBpCUJWG7yS-ABNEXzAAU-vb+JrY=rD8yBiiy0g@mail.gmail.com>
References: <CACeKOO1Gg6V4+eE8F+yCXRDwa_d5KAwk7OV+X-Z+tEMEstLMtg@mail.gmail.com>
	<[email protected]>
	<CACeKOO02V7_SBpCUJWG7yS-ABNEXzAAU-vb+JrY=rD8yBiiy0g@mail.gmail.com>

> 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

view thread (61+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: Proposal: Recent mutated table tracking in memory
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox