Hi, Thanks for the detailed review. I agree that the implementation in v3 has problems and should not be revised incrementally.
I have also looked again at the rescan approach in v2. I agree that the deadline is not reset, so a new conflict found by the next scan will be cancelled without another grace period. However, this only bounds how long recovery waits for each observed conflict; it does not bound how many new conflicts can be created. Until a signalled source actually exits, another backend may still import its snapshot and subsequently become a source for a snapshot retaining the same conflicting xmin. The same handoff can then happen again with the new exporter. I do not see an invariant in v2 that prevents this chain from continuing, so I am concerned that the outer rescan loop does not have a strict termination guarantee. Am I missing such an invariant? If there is no such invariant, preventing further propagation after the deadline appears to require some additional shared state, allowing conflicting imports to be rejected while recovery drains the remaining conflicts. Such a rejection may be consistent with the semantics of a finite standby delay, but I do not yet see a sufficiently simple way to publish and clear this state safely. I will rethink the approach before posting another version. Regards, Chee
