RE: Time delayed LR (WAS Re: logical replication restrictions) - Mailing list pgsql-hackers

From Takamichi Osumi (Fujitsu)
Subject RE: Time delayed LR (WAS Re: logical replication restrictions)
Date
Msg-id TYCPR01MB83730A45925B9680C40D92AFEDD69@TYCPR01MB8373.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: Time delayed LR (WAS Re: logical replication restrictions)  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Responses RE: Time delayed LR (WAS Re: logical replication restrictions)
List 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


Attachment

pgsql-hackers by date:

Previous
From: Antonin Houska
Date:
Subject: Re: RLS makes COPY TO process child tables
Next
From: "Takamichi Osumi (Fujitsu)"
Date:
Subject: RE: Time delayed LR (WAS Re: logical replication restrictions)