public inbox for [email protected]  

help / color / mirror / Atom feed

From: Nadav Shatz <[email protected]>
To: Tatsuo Ishii <[email protected]>
Cc: [email protected]
Subject: Re: Proposal: Recent mutated table tracking in memory
Date: Thu, 19 Feb 2026 06:40:21 +0200
Message-ID: <CACeKOO14e4h1na+J5TEPkHGuSVKA8YzL6gUaoCqgCqyoffCjHA@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <CACeKOO2QqpnML1OkQqqCCc+xG1d2M+sS7y7zE9vw5W-DXu+xKQ@mail.gmail.com>
	<[email protected]>
	<CACeKOO21jgrafj6RzO+ibLjBDUdDeQ0Tuu3tatkmGUdQi+GAAQ@mail.gmail.com>
	<[email protected]>

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 <[email protected]> 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
>

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: <CACeKOO14e4h1na+J5TEPkHGuSVKA8YzL6gUaoCqgCqyoffCjHA@mail.gmail.com>

* 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