The capture server of 2025 kept cluster caches consistent at the cost of a separate process and a Redis channel. Both engines can push a change to a connected client directly. This release listens.
Capture in process
- Two engines, one loop Informix push data through smart triggers and PostgreSQL LISTEN and NOTIFY fed by a generated trigger, emitting the same JSON document. The vendor classes carry protocol only.
- Not durable, and visible A rebuilt session reports a resync and dropped notifications report an overflow. Both engines deliver the previous row image, so column-level change detection works.
- Queryable Capture sessions are tables: idle ticks distinguish quiet from stalled, a watch can be suspended by an UPDATE so DDL can run, and a heartbeat line is logged per session.
The watch set
- Derived, not listed A local strategy derives the tables to watch from the cache eviction annotations. The hand-kept list had twenty-one tables with an eviction rule and no watch, and about twenty-seven watched tables driving nothing.
- Counters ignored Columns such as last access are excluded from change detection.
- Reconfigured in place A node's sync strategy changes without a restart, and Informix editions without replication are refused calmly rather than reported as a broken session.
One fewer process to run, one fewer channel to secure, and a watch set that cannot drift from the code it serves.