Re: Time delayed LR (WAS Re: logical replication restrictions)
От | Amit Kapila |
---|---|
Тема | Re: Time delayed LR (WAS Re: logical replication restrictions) |
Дата | |
Msg-id | CAA4eK1K_iKpmhDg+gwpz9rjEauBRBtj-_vp1D0e6K6WP4DpsoQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Time delayed LR (WAS Re: logical replication restrictions) (Kyotaro Horiguchi <horikyota.ntt@gmail.com>) |
Ответы |
Re: Time delayed LR (WAS Re: logical replication restrictions)
|
Список | pgsql-hackers |
On Mon, Jan 30, 2023 at 8:32 AM Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote: > > At Sat, 28 Jan 2023 04:28:29 +0000, "Takamichi Osumi (Fujitsu)" <osumi.takamichi@fujitsu.com> wrote in > > On Friday, January 27, 2023 8:00 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > > So, you have changed min_apply_delay from int64 to int32, but you haven't > > > mentioned the reason for the same? We use 'int' for the similar parameter > > > recovery_min_apply_delay, so, ideally, it makes sense but still better to tell your > > > reason explicitly. > > Yes. It's because I thought I need to make this feature consistent with the recovery_min_apply_delay. > > This feature handles the range same as the recovery_min_apply delay from 0 to INT_MAX now > > so should be adjusted to match it. > > INT_MAX can stick out of int32 on some platforms. (I'm not sure where > that actually happens, though.) We can use PG_INT32_MAX instead. > But in other integer GUCs including recovery_min_apply_delay, we use INT_MAX, so not sure if it is a good idea to do something different here. -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: