Re: Time delayed LR (WAS Re: logical replication restrictions)
| От | Kyotaro Horiguchi |
|---|---|
| Тема | Re: Time delayed LR (WAS Re: logical replication restrictions) |
| Дата | |
| Msg-id | 20230125.174316.531044799975189278.horikyota.ntt@gmail.com обсуждение исходный текст |
| Ответ на | Re: Time delayed LR (WAS Re: logical replication restrictions) (Amit Kapila <amit.kapila16@gmail.com>) |
| Список | pgsql-hackers |
At Wed, 25 Jan 2023 12:30:19 +0530, Amit Kapila <amit.kapila16@gmail.com> wrote in > On Wed, Jan 25, 2023 at 11:57 AM Kyotaro Horiguchi > <horikyota.ntt@gmail.com> wrote: > > > > At Tue, 24 Jan 2023 12:19:04 +0000, "Takamichi Osumi (Fujitsu)" <osumi.takamichi@fujitsu.com> wrote in > > > Attached the patch v20 that has incorporated all comments so far. > > > ... > > > > > > + in which case no additional wait is necessary. If the system clocks > > + on publisher and subscriber are not synchronized, this may lead to > > + apply changes earlier than expected, but this is not a major issue > > + because this parameter is typically much larger than the time > > + deviations between servers. Note that if this parameter is set to a > > > > This doesn't seem to fit our documentation. It is not our business > > whether a certain amount deviation is critical or not. How about > > somethig like the following? > > > > But we have a similar description for 'recovery_min_apply_delay' [1]. > See "...If the system clocks on primary and standby are not > synchronized, this may lead to recovery applying records earlier than > expected; but that is not a major issue because useful settings of > this parameter are much larger than typical time deviations between > servers." Mmmm. I thought that we might be able to gather the description (including other common descriptions, if any), but I didn't find an appropreate place.. Okay. I agree to the current description. Thanks for the kind explanation. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: