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

From: "Takamichi Osumi (Fujitsu)" <osumi(dot)takamichi(at)fujitsu(dot)com>
To: 'Andres Freund' <andres(at)anarazel(dot)de>
Cc: 'Amit Kapila' <amit(dot)kapila16(at)gmail(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, "smithpb2250(at)gmail(dot)com" <smithpb2250(at)gmail(dot)com>, "shiy(dot)fnst(at)fujitsu(dot)com" <shiy(dot)fnst(at)fujitsu(dot)com>, "vignesh21(at)gmail(dot)com" <vignesh21(at)gmail(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>, "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-02-11 05:44:47
Message-ID: TYCPR01MB83736A036CD5BA6677C9ABC5EDDF9@TYCPR01MB8373.jpnprd01.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi

On Saturday, February 11, 2023 11:10 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> On 2023-02-10 11:26:21 +0000, Takamichi Osumi (Fujitsu) wrote:
> > Subject: [PATCH v34] Time-delayed logical replication subscriber
> >
> > Similar to physical replication, a time-delayed copy of the data for
> > logical replication is useful for some scenarios (particularly to fix
> > errors that might cause data loss).
> >
> > This patch implements a new subscription parameter called
> 'min_apply_delay'.
> Has there been any discussion about whether this is actually best
> implemented on the client side? You could alternatively implement it on the
> sender.
>
> That'd have quite a few advantages, I think - you e.g. wouldn't remove the
> ability to *receive* and send feedback messages. We'd not end up filling up
> the network buffer with data that we'll not process anytime soon.
Thanks for your comments !

We have discussed about the publisher side idea around here [1]
but, we chose the current direction. Kindly have a look at the discussion.

If we apply the delay on the publisher, then
it can lead to extra delay where we don't need to apply.
The current proposed approach can take other loads or factors
(network, busyness of the publisher, etc) into account
because it calculates the required delay on the subscriber.

[1] - https://www.postgresql.org/message-id/20221215.105200.268327207020006785.horikyota.ntt%40gmail.com

Best Regards,
Takamichi Osumi

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2023-02-11 06:06:45 Re: possible memory leak in VACUUM ANALYZE
Previous Message John Naylor 2023-02-11 05:33:42 Re: [PoC] Improve dead tuple storage for lazy vacuum