On Monday, December 12, 2022 2:54 PM Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote:
> I asked about unexpected walsender termination caused by this feature but I
> think I didn't received an answer for it and the behavior is still exists.
>
> Specifically, if servers have the following settings, walsender terminates for
> replication timeout. After that, connection is restored after the LR delay elapses.
> Although it can be said to be working in that sense, the error happens
> repeatedly every about min_apply_delay internvals but is hard to distinguish
> from network troubles. I'm not sure you're deliberately okay with it but, I don't
> think the behavior causing replication timeouts is acceptable.
>
> > wal_sender_timeout = 10s;
> > wal_receiver_temeout = 10s;
> >
> > create subscription ... with (min_apply_delay='60s');
>
> This is a kind of artificial but timeout=60s and delay=5m is not an uncommon
> setup and that also causes this "issue".
>
> subscriber:
> > 2022-12-12 14:17:18.139 JST LOG: terminating walsender process due to
> > replication timeout
> > 2022-12-12 14:18:11.076 JST LOG: starting logical decoding for slot "s1"
> ...
Hi, Horiguchi-san
Thank you so much for your report!
Yes. Currently, how to deal with the timeout issue is under discussion.
Some analysis about the root cause are also there.
Kindly have a look at [1].
[1] -
https://www.postgresql.org/message-id/TYAPR01MB58669394A67F2340B82E42D1F5E29%40TYAPR01MB5866.jpnprd01.prod.outlook.com
Best Regards,
Takamichi Osumi
