| From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
|---|---|
| To: | amit(dot)kapila16(at)gmail(dot)com |
| Cc: | kuroda(dot)hayato(at)fujitsu(dot)com, osumi(dot)takamichi(at)fujitsu(dot)com, vignesh21(at)gmail(dot)com, euler(at)eulerto(dot)com, m(dot)melihmutlu(at)gmail(dot)com, andres(at)anarazel(dot)de, marcos(at)f10(dot)com(dot)br, pgsql-hackers(at)postgresql(dot)org, smithpb2250(at)gmail(dot)com |
| Subject: | Re: Time delayed LR (WAS Re: logical replication restrictions) |
| Date: | 2022-12-15 01:52:00 |
| Message-ID: | 20221215.105200.268327207020006785.horikyota.ntt@gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
At Wed, 14 Dec 2022 16:30:28 +0530, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote in
> On Wed, Dec 14, 2022 at 4:16 PM Hayato Kuroda (Fujitsu)
> <kuroda(dot)hayato(at)fujitsu(dot)com> wrote:
> > One idea to avoid that is to send the min_apply_delay subscriber option to publisher
> > and compare them, but it may be not sufficient. Because XXX_timout GUC parameters
> > could be modified later.
> >
>
> How about restarting the apply worker if min_apply_delay changes? Will
> that be sufficient?
Mmm. If publisher knows that value, isn't it albe to delay *sending*
data in the first place? This will resolve many known issues including
walsender's un-terminatability, possible buffer-full and status packet
exchanging.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Munro | 2022-12-15 02:22:59 | check_strxfrm_bug() |
| Previous Message | Kyotaro Horiguchi | 2022-12-15 01:46:11 | Re: Time delayed LR (WAS Re: logical replication restrictions) |