Date: Fri, 30 Jan 2026 17:09:50 +0900 (JST)
Message-Id: <20260130.170950.551399957723794225.ishii@postgresql.org>
To: nadav@tailorbrands.com
Cc: pgpool-hackers@lists.postgresql.org
Subject: Re: Proposal: Recent mutated table tracking in memory
From: Tatsuo Ishii <ishii@postgresql.org>
In-Reply-To: 
 <CACeKOO36wVT2k5b9G2J4XYvjNQTYf-ARoh8Lp-jbh7Yo8Qo+-w@mail.gmail.com>
References: <20260128.140840.463288103359200425.ishii@postgresql.org>
	<20260129.172810.828658334363427861.ishii@postgresql.org>
	<CACeKOO36wVT2k5b9G2J4XYvjNQTYf-ARoh8Lp-jbh7Yo8Qo+-w@mail.gmail.com>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/20260130.170950.551399957723794225.ishii%40postgresql.org>
Precedence: bulk

> 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