RE: Time delayed LR (WAS Re: logical replication restrictions)
От | Takamichi Osumi (Fujitsu) |
---|---|
Тема | RE: Time delayed LR (WAS Re: logical replication restrictions) |
Дата | |
Msg-id | TYCPR01MB83730A45925B9680C40D92AFEDD69@TYCPR01MB8373.jpnprd01.prod.outlook.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 |
Hi, On Wednesday, February 1, 2023 5:40 PM Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote: > At Wed, 1 Feb 2023 08:38:11 +0530, Amit Kapila <amit.kapila16@gmail.com> > wrote in > > On Wed, Feb 1, 2023 at 8:13 AM Kyotaro Horiguchi > > <horikyota.ntt@gmail.com> wrote: > > > > > > At Tue, 31 Jan 2023 15:12:14 +0530, Amit Kapila > > > <amit.kapila16@gmail.com> wrote in > > > > So, shall we check if the result of parse_int is in the range 0 > > > > and PG_INT32_MAX to ameliorate this concern? > > > > > > Yeah, it is exactly what I wanted to suggest. > > > > > > > If this works then we need to > > > > probably change the return value of defGetMinApplyDelay() to int32. > > > > > > I didn't thought doing that, int can store all values in the valid > > > range (I'm assuming we implicitly assume int >= int32 in bit width) > > > and it is the natural integer in C. Either will do for me but I > > > slightly prefer to use int there. > > > > > > > I think it would be clear to use int32 because the parameter where we > > store the return value is also int32. > > I'm fine with that. Thank you for confirming. Attached the updated patch v26 accordingly. I slightly adjusted the comments in defGetMinApplyDelay on this point as well. Best Regards, Takamichi Osumi
Вложения
В списке pgsql-hackers по дате отправления: