Re: Time delayed LR (WAS Re: logical replication restrictions)

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

In response to

Responses

Browse pgsql-hackers by date

  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