Re: Proposal: Recent mutated table tracking in memory

Thank you for the comments!

I agree with all of them. Let me know what you think of the changes and new
naming.

Please see attached another version of the patch.

On Fri, Jan 30, 2026 at 10:10 AM Tatsuo Ishii <ishii(at)postgresql(dot)org> wrote:

> > yes indeed, please find attached.
>
> Thanks. Here some comments on the patch:
>
> - It seems you use a table name (and schema) for a key to identify the
> TableMutationEntry and other objects. I think you should use table
> oids for the key because the same table name could exists in
> different schema. Moreover, if the database is different from the
> database when the map entry was created, a map look up could return
> incorrect result. In summary the key should be table oid and
> database oid (which is already done by query cache subsystem).
>
> - In the patch spin lock primitives are introduced. Why can't we use
> semaphore instead? A spin lock uses busy loop, which could increase
> the system load if the duration of locking becomes longer.
>
> - What would happen if the leader watchdog fails and other watchdog
> node take the place of the leader role?
>
> - pool_memory_map_get_ttl() and pool_memory_map_get_stats() are
> defined but are not used anywhere. Why do you have them?
>
> - I think "memory_map" is a too generic name. Can we use more specific
> name for the feature?
>
> 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