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 CAA4eK1+C_CRuVQ9gsUbCST6Cga6hkYO8zKWWQgUPGVFVD-J11A@mail.gmail.com
Whole thread Raw
In response to RE: Time delayed LR (WAS Re: logical replication restrictions)  ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>)
Responses RE: Time delayed LR (WAS Re: logical replication restrictions)  ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>)
List pgsql-hackers
On Fri, Dec 16, 2022 at 12:11 PM Hayato Kuroda (Fujitsu)
<kuroda.hayato@fujitsu.com> wrote:
>
> Dear Amit,
>
> > I also don't see the need for this mechanism for logical replication,
> > and in fact, why do we need to even wait for sending the existing WAL?
>
> Is it meant that logicalrep walsenders do not have to track WalSndCaughtUp and
> any pending data in the output buffer?
>

I haven't checked the details but I think what you are saying is correct.

>
> > Another related point to consider is what is the behavior of
> > synchronous replication when shutdown has been performed both in the
> > case of physical and logical replication especially when the
> > time-delayed replication feature is enabled?
>
> In physical replication without any failures, it seems that users can stop primary
> server even if the applications are delaying on secondary. This is because sent WALs
> are immediately flushed on secondary and walreceiver replies its position.
>

What happens when synchronous_commit's value is remote_apply and the
user has also set synchronous_standby_names to corresponding standby?

-- 
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: [PoC] Improve dead tuple storage for lazy vacuum
Next
From: Dilip Kumar
Date:
Subject: Re: Force streaming every change in logical decoding