Hello.
As reported in [1] it seems that walsender can suffer timeout in
certain cases. It is not clearly confirmed, but I suspect that
there's the case where LogicalRepApplyLoop keeps running the innermost
loop without receiving keepalive packet for longer than
wal_sender_timeout (not wal_receiver_timeout). Of course that can be
resolved by giving sufficient processing power to the subscriber if
not. But if that happens between the servers with the equal processing
power, it is reasonable to "fix" this. Theoretically I think this can
happen with equally-powered servers if the connecting network is
sufficiently fast. Because sending reordered changes is relatively
simple and fast than apllying the changes on subscriber.
I think we don't want to call GetCurrentTimestamp every iteration of
the innermost loop. Even if we call it every N iterations, I don't
come up with a proper N that fits any workload. So one possible
solution would be using slgalrm. Is it worth doing? Or is there any
other way?
Even if we won't fix this, we might need to add a description about
this restriciton in the documentation?
Any thougths?
[1] https://www.postgresql.org/message-id/CAEDsCzhBtkNDLM46_fo_HirFYE2Mb3ucbZrYqG59ocWqWy7-xA%40mail.gmail.com
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center