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

Поиск
Список
Период
Сортировка
От Kyotaro Horiguchi
Тема Re: Time delayed LR (WAS Re: logical replication restrictions)
Дата
Msg-id 20230130.120212.227464179366497588.horikyota.ntt@gmail.com
обсуждение исходный текст
Ответ на RE: Time delayed LR (WAS Re: logical replication restrictions)  ("Takamichi Osumi (Fujitsu)" <osumi.takamichi@fujitsu.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)  ("Takamichi Osumi (Fujitsu)" <osumi.takamichi@fujitsu.com>)
Список pgsql-hackers
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.

IMHO, I think we don't use int as a catalog column and I agree that
int32 is sufficient since I don't think more than 49 days delay is
practical. On the other hand, maybe I wouldn't want to use int32 for
intermediate calculations.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



В списке pgsql-hackers по дате отправления:

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: Prefetch the next tuple's memory during seqscans
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Time delayed LR (WAS Re: logical replication restrictions)