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

From: "Takamichi Osumi (Fujitsu)" <osumi(dot)takamichi(at)fujitsu(dot)com>
To: 'Amit Kapila' <amit(dot)kapila16(at)gmail(dot)com>
Cc: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, "smithpb2250(at)gmail(dot)com" <smithpb2250(at)gmail(dot)com>, "vignesh21(at)gmail(dot)com" <vignesh21(at)gmail(dot)com>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, "shveta(dot)malik(at)gmail(dot)com" <shveta(dot)malik(at)gmail(dot)com>, "dilipbalaut(at)gmail(dot)com" <dilipbalaut(at)gmail(dot)com>, "euler(at)eulerto(dot)com" <euler(at)eulerto(dot)com>, "m(dot)melihmutlu(at)gmail(dot)com" <m(dot)melihmutlu(at)gmail(dot)com>, "andres(at)anarazel(dot)de" <andres(at)anarazel(dot)de>, "marcos(at)f10(dot)com(dot)br" <marcos(at)f10(dot)com(dot)br>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: RE: Time delayed LR (WAS Re: logical replication restrictions)
Date: 2023-01-28 04:28:29
Message-ID: TYCPR01MB83735C9C1B0F0D01199BD436EDCD9@TYCPR01MB8373.jpnprd01.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Friday, January 27, 2023 8:00 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> On Fri, Jan 27, 2023 at 1:39 PM Takamichi Osumi (Fujitsu)
> <osumi(dot)takamichi(at)fujitsu(dot)com> wrote:
> >
> > On Wednesday, January 25, 2023 11:24 PM I wrote:
> > > Attached the updated v22.
> > Hi,
> >
> > During self-review, I noticed some changes are required for some
> > variable types related to 'min_apply_delay' value, so have conducted
> > the adjustment changes for the same.
> >
>
> 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.

> Few comments
> =============
> 1.
> @@ -70,6 +70,8 @@ CATALOG(pg_subscription,6100,SubscriptionRelationId)
> BKI_SHARED_RELATION BKI_ROW
> XLogRecPtr subskiplsn; /* All changes finished at this LSN are
> * skipped */
>
> + int32 subminapplydelay; /* Replication apply delay (ms) */
> +
> NameData subname; /* Name of the subscription */
>
> Oid subowner BKI_LOOKUP(pg_authid); /* Owner of the subscription */
>
> Why are you placing this after subskiplsn? Earlier it was okay because we want
> the 64 bit value to be aligned but now, isn't it better to keep it after subowner?
Moved it after subowner.

> 2.
> +
> + diffms = TimestampDifferenceMilliseconds(GetCurrentTimestamp(),
> + TimestampTzPlusMilliseconds(finish_ts,
> + MySubscription->minapplydelay));
>
> The above code appears a bit unreadable. Can we store the result of
> TimestampTzPlusMilliseconds() in a separate variable say "TimestampTz
> delayUntil;"?
Agreed. Fixed.

Attached the updated patch v24.

Best Regards,
Takamichi Osumi

Attachment Content-Type Size
v24-0001-Time-delayed-logical-replication-subscriber.patch application/octet-stream 81.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2023-01-28 04:53:07 Re: lockup in parallel hash join on dikkop (freebsd 14.0-current)
Previous Message Andres Freund 2023-01-28 04:26:25 Re: Something is wrong with wal_compression