public inbox for [email protected]
help / color / mirror / Atom feedFrom: Tatsuo Ishii <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: Proposal: Recent mutated table tracking in memory
Date: Wed, 11 Feb 2026 19:28:45 +0900 (JST)
Message-ID: <[email protected]> (raw)
In-Reply-To: <CACeKOO2QqpnML1OkQqqCCc+xG1d2M+sS7y7zE9vw5W-DXu+xKQ@mail.gmail.com>
References: <[email protected]>
<CACeKOO2HVSKqu+Zp8WC+QhE7yS9LBLiifwRpQVfjOEAka_YpKw@mail.gmail.com>
<CACeKOO2QqpnML1OkQqqCCc+xG1d2M+sS7y7zE9vw5W-DXu+xKQ@mail.gmail.com>
> 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 <[email protected]> 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 <[email protected]> wrote:
>>
>>> From: Tatsuo Ishii <[email protected]>
>>> Subject: Re: Proposal: Recent mutated table tracking in memory
>>> Date: Tue, 03 Feb 2026 16:43:53 +0900 (JST)
>>> Message-ID: <[email protected]>
>>>
>>> > 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
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