Re: Proposal: Recent mutated table tracking in memory

> Hi Tatsuo,
>
> After reading more about disable_load_balance_on_write=dml_adaptive i came
> to the thought that this feature is actually an "extension" of that since
> it covers "global" and not just per transaction behavior. in any case i
> think it makes more sense that it sits under
> the disable_load_balance_on_write and not as a standalone for clarity.
>
> I'm attaching below an updated patch with these adjustments.
>
> Please let me know what you think.

I worry about the transactional behavior with the patch:

+ This means that if a transaction is rolled back, the table remains marked as stale until
+ the TTL expires, even though no actual data modification occurred. This is by design:

This allows attackers to issue simple command continuously to
effectively disable load balance (and increase the load of primary) in
whole system:

BEGIN;
UPDATE t1 SET i = 1 WHERE FALSE;
ROLLBACK;

I think if the patch allows that, we cannot accept the patch.

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

> On Fri, Feb 6, 2026 at 1:29 PM Nadav Shatz <nadav(at)tailorbrands(dot)com> wrote:
>
>> Hi Tatsuo,
>>
>> Thank you for all the great comments and questions! I took under
>> consideration all of them either adding support/tests or detailing the
>> limitations in the docs.
>>
>> Let me know what you think of the latest patch attached here
>>
>> On Wed, Feb 4, 2026 at 1:23 AM Tatsuo Ishii <ishii(at)postgresql(dot)org> wrote:
>>
>>> From: Tatsuo Ishii <ishii(at)postgresql(dot)org>
>>> Subject: Re: Proposal: Recent mutated table tracking in memory
>>> Date: Tue, 03 Feb 2026 16:43:53 +0900 (JST)
>>> Message-ID: <20260203(dot)164353(dot)362943818466117773(dot)ishii(at)postgresql(dot)org>
>>>
>>> > Hi Nadav,
>>> >
>>> > Thank you for updating the patch!
>>> >
>>> >> Thank you for the comments!
>>> >>
>>> >> I agree with all of them. Let me know what you think of the changes
>>> and new
>>> >> naming.
>>> >
>>> > I still think "memory_map" is too generic. Anything put on memory for
>>> > data mapping could be called "memory map". I recommend to change the
>>> > name to more feature specific one: What about replacing "memory_map"
>>> > with "track_table_mutation"? It's a little bit longer name but it
>>> > clearly represents the feature. Any better ideas are welcome.
>>> >
>>> > - memory_map_enabled: Enable/disable the feature (default: off)
>>> > - memory_map_ttl_factor: TTL multiplier for replication delay (default:
>>> 5.0)
>>> > - memory_map_cold_start_duration: Cold start period in ms (default:
>>> 2000)
>>> > - memory_map_table_buckets: Hash buckets for table map (default: 1024)
>>> > - memory_map_table_size: Max tracked tables (default: 2048)
>>> > - memory_map_query_buckets: Hash buckets for query cache (default: 2048)
>>> > - memory_map_query_cache_size: Max cached queries (default: 10000)
>>> >
>>> > Also I feel memory_map_query_cache_size is confusing because there's
>>> > already "query cache" feature in pgpool. Can we change it something
>>> > like "query_parse_cache_size"?
>>> >
>>> > Review comments:
>>> >
>>> > (1) Why the regression test is 45? Shouldn't it be 42? (the last
>>> > feature test is 041.external_replication_delay).
>>> >
>>> > (2) You enhance the patch to deal with leader watch changing. That's
>>> > good. However, I don't see a test case for it in test.sh.
>>> >
>>> > (3) It seems the patch does not support TRUNCATE, MERGE, PREPARE and
>>> > WITH + updating. If so, it should be noted in the docs as a limitation
>>> > of the feature.
>>>
>>> (4) It seems the patch does not consider transactions. If an UPDATE is
>>> performed in a transaction and the transaction gets rollbacked, load
>>> balance is disabled despite that fact that the table modification did
>>> not happen.
>>>
>>> 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
>>
>
>
> --
> Nadav Shatz
> Tailor Brands | CTO