So is there any solution to this issue?
I did try to increase the wal_sender_timeout and it broke the pub/sub.
I increased the wal_receiver_timeout and it wouldn't attempt to restart the subscription until that time elapsed.
Due to that, the WAL segments got removed by the time it came up again and it stopped working.
So given that the publisher is publishing at a higher rate than the subscriber is subscribing, what can be done?
On Fri, Sep 10, 2021 at 9:26 AM Kyotaro Horiguchi <horikyota.ntt@xxxxxxxxx> wrote:
At Thu, 9 Sep 2021 16:06:25 +0900, Abhishek Bhola <abhishek.bhola@xxxxxxxxxxxxxxx> wrote in
> sourcedb:~$ postgres --version
> postgres (PostgreSQL) 11.6
>
> Sorry for missing this information.
> But looks like this fix is already included in the version I am running.
Ok. I'm not sure but there may be a case where too-busy (or too poor
relative to the publisher) subscriber cannot send a response for a
long time. Usually keep-alive packets sent from publisher causes
subscriber response even while busy time but it seems that if
subscriber applies changes more than two times slower than the
publisher sends, subscriber doesn't send a response in the timeout
window.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
This correspondence (including any attachments) is for the intended recipient(s) only. It may contain confidential or privileged information or both. No confidentiality or privilege is waived or lost by any mis-transmission. If you receive this correspondence by mistake, please contact the sender immediately, delete this correspondence (and all attachments) and destroy any hard copies. You must not use, disclose, copy, distribute or rely on any part of this correspondence (including any attachments) if you are not the intended recipient(s).
