Re: Time delayed LR (WAS Re: logical replication restrictions)
От | Kyotaro Horiguchi |
---|---|
Тема | Re: Time delayed LR (WAS Re: logical replication restrictions) |
Дата | |
Msg-id | 20221215.105200.268327207020006785.horikyota.ntt@gmail.com обсуждение исходный текст |
Ответ на | Re: Time delayed LR (WAS Re: logical replication restrictions) (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: Time delayed LR (WAS Re: logical replication restrictions)
|
Список | pgsql-hackers |
At Wed, 14 Dec 2022 16:30:28 +0530, Amit Kapila <amit.kapila16@gmail.com> wrote in > On Wed, Dec 14, 2022 at 4:16 PM Hayato Kuroda (Fujitsu) > <kuroda.hayato@fujitsu.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
В списке pgsql-hackers по дате отправления: