From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
---|---|
To: | osumi(dot)takamichi(at)fujitsu(dot)com |
Cc: | smithpb2250(at)gmail(dot)com, euler(at)eulerto(dot)com, m(dot)melihmutlu(at)gmail(dot)com, andres(at)anarazel(dot)de, amit(dot)kapila16(at)gmail(dot)com, marcos(at)f10(dot)com(dot)br, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Time delayed LR (WAS Re: logical replication restrictions) |
Date: | 2022-12-12 05:54:09 |
Message-ID: | 20221212.145409.1425479535653769807.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello.
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"
...
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2022-12-12 06:23:22 | Re: ExecRTCheckPerms() and many prunable partitions (checkAsUser) |
Previous Message | Zheng Li | 2022-12-12 05:05:22 | Re: Testing DDL Deparser |