Re: Proposal: Recent mutated table tracking in memory

> 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