Re: Proposal: Recent mutated table tracking in memory

Added some handling for possible causes - works now.

On Thu, Feb 19, 2026 at 6:40 AM Nadav Shatz <nadav(at)tailorbrands(dot)com> wrote:

> Thanks! I’ll look into it and share an updated patch
>
> Nadav Shatz
> Tailor Brands | CTO
>
>
> On Thu, Feb 19, 2026 at 1:51 AM Tatsuo Ishii <ishii(at)postgresql(dot)org> wrote:
>
>> > Hi Tatsuo,
>> >
>> > Thank you for the careful review. You raised an important concern.
>> I've
>> > addressed it in the updated patch ― here's the explanation:
>> >
>> > The attack scenario you describe is now handled. In the updated patch,
>> > writes inside explicit transactions are only flushed to the
>> shared-memory
>> > table map at COMMIT time. If the transaction is rolled back, the table
>> is
>> > never marked as stale. So the attack pattern:
>> >
>> > BEGIN;
>> > UPDATE t1 SET i = 1 WHERE FALSE;
>> > ROLLBACK;
>> >
>> > has zero effect on the shared-memory table map. The
>> dml_adaptive_global
>> > mode piggybacks on the existing dml_adaptive per-transaction write list
>> > (transaction_temp_write_list). On COMMIT, the accumulated table names
>> are
>> > resolved to OIDs and flushed to shared memory. On ROLLBACK,
>> > the list is simply discarded (the existing dml_adaptive behavior).
>> >
>> > For autocommit statements (outside explicit transactions), tables are
>> > marked immediately ― but in that case the write is committed, so this is
>> > correct.
>> >
>> > Regression test included. Test 042 now includes:
>> > - Test 10: verifies that BEGIN; INSERT; ROLLBACK; SELECT does NOT
>> route
>> > the SELECT to primary
>> > - Test 11: verifies that BEGIN; INSERT; COMMIT; SELECT DOES route the
>> > SELECT to primary
>> >
>> > Additional context on the threat model:
>> >
>> > 1. This feature requires disable_load_balance_on_write =
>> > 'dml_adaptive_global' ― it is opt-in, not enabled by default. Operators
>> who
>> > enable it accept documented trade-offs (additional shared memory,
>> TTL-based
>> > staleness window).
>> > 2. An attacker who can connect and execute SQL against pgpool already
>> has
>> > the ability to cause far more damage (DROP TABLE, mass DELETEs, resource
>> > exhaustion via expensive queries, connection flooding, etc.). The
>> > table-marking via committed writes is a minor concern compared to
>> > those vectors. Authentication, connection limits, and network security
>> > are the appropriate defenses at that layer.
>> > 3. Even in the worst case (an attacker commits real writes in a loop),
>> > the impact is bounded: the stale marking is temporary (TTL-based,
>> typically
>> > a few seconds), and only affects load-balancing decisions ― it doesn't
>> > cause data loss or correctness issues.
>> > 4. The existing dml_adaptive mode has analogous behavior: within a
>> > transaction, a write to table T causes all reads of T to go to primary
>> for
>> > the remainder of that transaction. The only difference is scope ―
>> > dml_adaptive_global extends this across sessions with a TTL.
>> >
>> > Thanks!
>>
>> Thank you for the patch. While I am looking into it, I noticed a
>> regression test failure.
>>
>> t-ishii$ ./regress.sh 04[12]
>> creating pgpool-II temporary installation ...
>> :
>> :
>> testing 041.external_replication_delay...ok.
>> testing 042.track_table_mutation...failed.
>> out of 2 ok:1 failed:1 timeout:0
>>
>> However if I run 042 only, it succeeds.
>>
>> t-ishii$ ./regress.sh 042
>> :
>> :
>> testing 042.track_table_mutation...ok.
>> out of 1 ok:1 failed:0 timeout:0
>>
>> Can you please take a look at this? log/042.track_table_mutation
>> attached.
>>
>> Best regards,
>> --
>> Tatsuo Ishii
>> SRA OSS K.K.
>> English: http://www.sraoss.co.jp/index_en/
>> Japanese:http://www.sraoss.co.jp
>>
>

--
Nadav Shatz
Tailor Brands | CTO