Re: Recovery conflict resolution misses backends that import snapshots

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