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

From Amit Kapila
Subject Time delayed LR (WAS Re: logical replication restrictions)
Date
Msg-id CAA4eK1J6xLUJNR1tXEidnpWFkX8afF40MCT4x7vgojKXBtwZMg@mail.gmail.com
Whole thread Raw
In response to Re: logical replication restrictions  (vignesh C <vignesh21@gmail.com>)
Responses Re: Time delayed LR (WAS Re: logical replication restrictions)
Re: Time delayed LR (WAS Re: logical replication restrictions)
List pgsql-hackers
Hi,

The thread title doesn't really convey the topic under discussion, so
changed it. IIRC, this has been mentioned by others as well in the
thread.

On Sat, Nov 12, 2022 at 7:21 PM vignesh C <vignesh21@gmail.com> wrote:
>
> Few comments:
> 1) I feel if the user has specified a long delay there is a chance
> that replication may not continue if the replication slot falls behind
> the current LSN by more than max_slot_wal_keep_size. I feel we should
> add this reference in the documentation of min_apply_delay as the
> replication will not continue in this case.
>

This makes sense to me.

> 2) I also noticed that if we have to shut down the publisher server
> with a long min_apply_delay configuration, the publisher server cannot
> be stopped as the walsender waits for the data to be replicated. Is
> this behavior ok for the server to wait in this case? If this behavior
> is ok, we could add a log message as it is not very evident from the
> log files why the server could not be shut down.
>

I think for this case, the behavior should be the same as for physical
replication. Can you please check what is behavior for the case you
are worried about in physical replication? Note, we already have a
similar parameter for recovery_min_apply_delay for physical
replication.

-- 
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: vignesh C
Date:
Subject: Re: Support logical replication of DDLs
Next
From: Sergey Shinderuk
Date:
Subject: Re: Schema variables - new implementation for Postgres 15