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

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: osumi(dot)takamichi(at)fujitsu(dot)com
Cc: amit(dot)kapila16(at)gmail(dot)com, smithpb2250(at)gmail(dot)com, vignesh21(at)gmail(dot)com, kuroda(dot)hayato(at)fujitsu(dot)com, shveta(dot)malik(at)gmail(dot)com, dilipbalaut(at)gmail(dot)com, euler(at)eulerto(dot)com, m(dot)melihmutlu(at)gmail(dot)com, andres(at)anarazel(dot)de, marcos(at)f10(dot)com(dot)br, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Time delayed LR (WAS Re: logical replication restrictions)
Date: 2023-01-30 03:02:12
Message-ID: 20230130.120212.227464179366497588.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Sat, 28 Jan 2023 04:28:29 +0000, "Takamichi Osumi (Fujitsu)" <osumi(dot)takamichi(at)fujitsu(dot)com> wrote in
> On Friday, January 27, 2023 8:00 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2023-01-30 03:21:05 Re: Time delayed LR (WAS Re: logical replication restrictions)
Previous Message David Rowley 2023-01-30 02:23:47 Re: Prefetch the next tuple's memory during seqscans