On Wed, Mar 8, 2023 at 3:30 AM Nathan Bossart <nathandboss...@gmail.com> wrote: > > On Mon, Mar 06, 2023 at 07:27:59PM +0300, Önder Kalacı wrote: > > On the other hand, we already have a similar problem with > > recovery_min_apply_delay combined with hot_standby_feedback [1]. > > So, that probably is an acceptable trade-off for the pgsql-hackers. > > If you use this feature, you should be even more careful. > > Yes, but it's possible to turn off hot_standby_feedback so that you don't > incur bloat on the primary. And you don't need to store hours or days of > WAL on the primary.
Right. This side effect belongs to the combination of recovery_min_apply_delay and hot_standby_feedback/replication slot. recovery_min_apply_delay itself can be used even without this side effect if we accept other trade-offs. When it comes to this time-delayed logical replication feature, there is no choice to avoid the side effect for users who want to use this feature. > I'm very late to this thread, but IIUC you cannot > avoid blocking VACUUM with the proposed feature. Right. > IMO the current set of > trade-offs (e.g., unavoidable bloat and WAL buildup) would make this > feature virtually unusable for a lot of workloads, so it's probably worth > exploring an alternative approach. It might require more engineering effort for alternative approaches such as one I proposed but the feature could become better from the user perspective. I also think it would be worth exploring it if we've not yet. Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
