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

From Amit Kapila
Subject Re: Time delayed LR (WAS Re: logical replication restrictions)
Date
Msg-id CAA4eK1Jx2A=v2rj24pkhge_UDzhrx5WHbpCoyfMB6cOsuZsMOA@mail.gmail.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
On Tue, Jan 31, 2023 at 1:40 PM Kyotaro Horiguchi
<horikyota.ntt@gmail.com> wrote:
>
> Hi, Kuroda-san, Thanks for the detailed study.
>
> At Tue, 31 Jan 2023 07:06:40 +0000, "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com> wrote in
> > Therefore, I think we can say that modern platforms that are supported by PostgreSQL define int as 32-bit.
> > It satisfies the condition sizeof(int) <= sizeof(int32), so we can keep to use INT_MAX.
>
> Yeah, I know that that's practically correct.  Just I wanted to make
> clear is whether we (always) assume int == int32. I don't want to do
> that just because that works. Even though we cannot be perfect, in
> this particular case the destination space is explicitly made as
> int32.
>

So, shall we check if the result of parse_int is in the range 0 and
PG_INT32_MAX to ameliorate this concern? If this works then we need to
probably change the return value of defGetMinApplyDelay() to int32.

-- 
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: Reducing power consumption on idle servers
Next
From: Peter Eisentraut
Date:
Subject: Re: Timeline ID hexadecimal format