Re: Proposal: Recent mutated table tracking in memory

> 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